ITSM was once a wholly new approach to discuss and implement IT. So, what turned ITSM's meaning to that of a four-letter word for today's IT professionals?
IT service management provides guidance on how to design, deliver, manage and improve IT services for corporate stakeholders. It creates a common language for IT across business verticals and disciplines. ITSM processes keep chaos and disorder at bay, so IT can meet expectations predictably and repeatedly. At least, that's how it's supposed to work.
ITSM's meaning was lost in translation
ITSM has suffered from a dogmatic approach to frameworks rather than adaptation to diverse IT organizations. Early training programs lacked a focus on practical implementations and instead promoted certification tracks on one framework or methodology. The first wave of adopters largely implemented ITSM processes without a business-related objective or metrics to tell them if these moves created value.
The intense organizational change required to recognize ITSM payoffs is hard to keep up. Even in some successful implementations, IT leaders find that staff revert to old practices as soon as the ITSM project wraps up. Rather than dissolving silos, overly arduous ITSM processes seem to reinforce their walls.
ITSM adherents report more satisfied users and efficient IT operations. But many IT organizations discover that the ITSM processes and procedures that look good in books don't meet their needs. In the evolution of ITSM, implementers worried more about tool installations and applying cursory process designs than about providing value and outcomes for the business. As a result, service catalogs resembled menus of things done by IT, without relevance to business needs.
The ITSM terminology that gave IT staff a common language did not translate to users: business staff and customers. This meant already limited IT communication outside the department became baffling to interpret. It exacerbated user frustration during an outage or incident.
Without support from IT workers or their customers and with ITSM frameworks seemingly disconnected from what is happening in corporate server rooms, IT leadership and staff now question the value and meaning of ITSM. New ideas around how best to manage IT services -- DevOps is a popular example -- foment the confusion around the meaning of ITSM.
Give ITSM meaning in business context
Rather than kill ITSM, the problems with adoption and business-side unrest force IT organizations to hit the reset button on service delivery and management.
Businesses demand a combination of speed and responsiveness from IT -- what is commonly referred to as agility -- with judicious controls applied at appropriate times. ITSM processes and technology under their guidance must work seamlessly to deliver an outstanding, differentiated experience for the customer.
To start a new ITSM strategy, develop business acumen among IT leaders so that they understand what will help achieve results for workers.
Map technology to business value chains to identify where IT contributes to or supports the company. Companies expect technology to be an integrated part of business processes, not an additional layer of overhead. ITSM can ensure the appropriate and justifiable use of technology to deliver value to customers.
Governance actually enables business competitiveness when it ensures that IT defines and enforces policies aligned with business goals and risks. ITSM processes built around the business enable it to realize identified benefits, rather than holding it back.
Understanding business motivation and strategy is crucial for better ITSM processes. IT organizations need a framework that helps them enable and deliver business capabilities.
A myopic approach to service delivery won't cut it. Just as there is no one-size-fits-all approach to business, there can be no one-size-fits-all approach to ITSM. ITSM shouldn't be limited to one framework or methodology. Instead, approach ITSM implementation like a craftsman, pulling components of various frameworks and methodologies together to deliver outcomes tailored to the business. Research the strengths and the weaknesses of established methodologies, and use the right tools for the job.
Process design lays the groundwork for IT automation, creating repeatable and consistent steps that automation can speed up considerably.
The common language of ITSM matters to IT organizations, but learn to talk about service management in business terms: How will the business realize value from investments in technology? IT leaders can no longer measure success only in technological terms; instead, track metrics that show how IT service delivery and management positively or negatively influence the business. Collaboration -- not isolation -- is the name of the game.
Despite all of the past challenges with ITSM, IT has a chance to get it right -- for the business and for IT's staff.
Pam Erskine has over 15 years of leadership experience in IT and service transformation, including organizational change and IT-business alignment and integration. She authored ITIL and Organizational Change. An ITIL expert, she also has accreditations and certifications in visual strategic planning, Kepner-Fourie, Six Sigma, COBIT, DevOps and Lean IT, as well as experience as a help desk director. Follow Pam at @adopt_itsm, and visit her blog at AdOPT.
Jay Stuart has been a contributing member of the ITSM community for over 15 years, serving in a number of industry volunteer leadership roles. He is an educator, mentor and practitioner of ITSM and is currently an ITSM leader at GE Capital US Holdings.
Doug Tedder is the principal consultant of Tedder Consulting LLC, a service management and IT governance consultancy. He guides IT organizations to become business partners that deliver value through attention to detail, industry knowledge, emotional intelligence and the ability to see the big picture and make it actionable. Follow Doug at @dougtedder, or read his blog at Tedder Consulting.
Pair DevOps with the internet of things for improved application performance
DevOps changed the rules -- but it didn't eradicate them
Organizations struggle to implement DevOps without skilled workers