5 Tips For Developing An ITSM Strategic Road Map
For our next interview on this blog, I’m talking to Pink Elephant’s AVP Product Strategy, Troy DuMoulin, who blogs regularly and – I think – with lots of insight. We don’t always agree (see my recent post) but anyone who themes his blog around the Hitchhiker’s Guide to the Galaxy has got to be worth reading, and the content rewards the effort.
One of Troy’s sessions at the Conference next year will be 5 Tips For Developing An ITSM Strategic Road Map. Many IT executives and senior managers are challenged with creating and communicating a “road map” that includes the key strategic ingredients to successfully execute an ITSM implementation project. While all organizations differ, there are some very important commonalities that should be considered in each case, and that could mean the difference between success and failure. Do you know what these are? Join Troy, who is a highly seasoned expert of many strategic consulting engagements, to learn 5 important tips from his Consultant’s Case Book.
Here, then, is a podcast of the two of us discussing these strategic tips. http://www.pinkelephant.com/ressource/Pinkcast/troy_dumoulin.mp3
And for those of you who, like me, prefer to hear the bus coming when I walk around - and get all tangled up in those little wires anyway - here are some initial questions we kicked around before the interview:
Skep: If asked a few months later, people often only remember one message from a presentation. What is the one thing you want them to recall from this one?
Troy: Process documentation and the underlying IT tools are simply a means to the end and not the end in and of themselves.
Skep: Why should I go to this session? What’s in it for me? Not my boss, not the universe, me. Can you explain a personal benefit?
Troy: In this session I describe 5 critical and strategic success factors that you need to be aware of to be successful at your ITSM projects so that they don’t leave a negative impact on your career. Self preservation by either achievement of success, risk avoidance or at least being the person who raised the red flag at the approaching danger are all strong personal motivators.
Skep: You refer to the need for ITSM projects to be integrated, to not create more silos. I find ITSM is a great tool for breaking down other existing silos too. Do you find that?
Troy: Yes the nature of enterprise goals and shared processes supports the recognition and re-discovery that it each technical silo is part of a bigger whole with a shared goal of service delivery and management. ITSM helps to reverse several hundred years of organizational design based on the principles of task specialization which artificially break down processes (both manufacturing and information processes) down into individual component tasks. However, left to our own devices we will adopt ITIL processes and create a new silo for each one with limited to no integration at either a process, tool or data layer.
Skep: How do you get a feel or measure for cultural readiness for ITSM?
Troy: The model I discuss in the presentation has key paradigm shifts which occur at each stage.
Technical: focus is on improving support processes
System / Service: A realization that it components and domains do not live in mythical isolation and that there is a need to manage and understand dependencies and how each component contributes to a larger context.
Customer Focused: The IT function has an enterprise mode of delivering services regardless of what internal or external functions contribute to the value chain
Partner Focused: The IT Function realizes that it is one of many service providers in the business context and is really no different than the Facilities group, the manufacturing plant, HR etc. The subtle change is that there is no longer a separation of IT and Business functions.
Value Chain Focused: The IT function and the business both fully realize that the information technology is as much a part of the primary business processes or “Line” as older business technologies.
Our experience shows that certain processes are not likely to be successful for adoption until a certain level has been achieved.
Skep: How much do tools really matter to ITSM?
Troy: The reality is that to even approximate the level of integration and process collaboration across groups tools are a necessary enabler. I have had personal experience using Excel and other rudimentary tools with some but very limited effect.
Skep: If an organization is still at zero on ITSM, do they need a roadmap right away? Do they know enough to plan well ahead? Don’t they need to get their feet wet first?
Troy: Based on experience there is a typical adoption pattern that is based on two inputs. 1) The logical sequencing of processes based on the fact that certain processes need to be at a level of maturity before another process can be successfully implemented. 2) The cultural readiness of an organization to adopt certain processes. eg: What is the business driver for a Service Catalog or CMDB if an organization does not know or care about services? Good luck with Service Portfolio Management if you don’t have an enterprise view of services.
So be careful if you step into the deep end with those feet. The footing may be too deep for success.
I hope you listened to the podcast too – Troy went into more depth about the strategy of ITSM and the great models in his presentation. And this is only a foretaste of the session at the Conference next year – be there!
Next entry: The EHOBOK maturity model
Previous entry: Introduction to EHOBOK
