Thursday, November 27, 2008
7 Enablers for ITSM Expanded - Ability To Deploy
Designing An ITIL Process Is The Easy Part
Up until now, the enablers we have discussed relate primarily to the design, build and test phases of the project; however, by the statement “Ability To Deploy” I am specifically referring to the political will and authority to deploy / impose a new method of working and new tools across the scope of the organization that now must comply with these new ITSM processes. In our experience and research, this is a primary point of failure for many companies (it all looked great until others were required to change the current behaviors).
While it takes significant effort to design, document and test your ITSM deliverables, it is at the point of actually rolling out changes to the functional groups and departments that many ITSM projects hit the proverbial brick wall. Whether it comes in the form of open rejection of the new process and tools or it rears its head as a delay tactic, many ITSM projects find themselves mired in the quagmire of inter-company politics and fail at the point of delivery without ever having realized any value to the organization making the investment.
Typical Deployment Challenge Scenarios:
- The Filibuster: One or more of the groups you are deploying to find some urgent reason to put off changing to the new way of working based on a whole series of excuses (either real or imaginary) not related to the project directly, as this would appear as if they were not supportive.
- The Never Ending Pilot: Based on the principle of a pilot rollout to a designated group, the testing of process and tools generates dozens of critical improvement requirements that somehow did not come up during the months of design and review by the very same group.
- The Perfectionist Syndrome: The primary stakeholders responsible for signing off on the design and characteristics of the process and tool requirements refuse to accept that improvement – not perfection – is the goal, and that certain improvements can come later. This scenario is very typical for an organization that has had difficulty managing changes in scope during the project lifecycle.
- The Tool Development Backlog: For ITSM programs, the process automation tool/suite is often used by several processes that have already been deployed or are being so while other processes are being designed. The challenge that often arises at this point is the fact that the developers / administrators become the primary bottleneck in that they cannot cope with all of the demands for configuration and customization they are receiving from multiple process groups. This becomes even more of an issue if request for tool enhancements are not approved, prioritized and scheduled through a strict Change Management process.
These are the typical scenarios that come painfully to my mind. I am sure you have your own and I would love to hear them.
Troy’s Thoughts What Are Yours?
“Experience has taught us that men will not adopt and carry into execution measures the best calculated for their own good without the intervention of a coercive power” ~George Washington
Thursday, November 20, 2008
7 Enablers for ITSM Expanded - Integrated Tools
When You Are Not Integrated You Are Isolated
It is no secret that to even get close to the process integration that ITIL suggests as good practice, it is critical to consider workflow automation and tool requirements; however, that being said, have you also considered that underpinning these processes is data? Data is passed back and forth between processes as tasks, workflow records, approvals, SLA time frames, costs and configuration item details.
Invariably, the activities, inputs and outputs of ITSM are represented in a digital form that is shared by many processes at various times and for various reasons. This digital web of information flow is ultimately represented by an ITSM tool and data architecture that supports the over all vision and strategy of an enterprise IT function, fulfilling the role of a key business partner and service provider.
Underpinning the integrated ITIL process model must be an integrated ITSM tool strategy that is supported by a shared data model.
In the ITSM community we are very comfortable talking about the IT governance and process levels of service management; however, we often fail to consider the tool and data definition that is required to make it real. In my personal experience it is always the tool element of the ITIL project that takes the longest time – not the process design!
At the heart of this challenge is the silo or domain approach to how we purchase IT management tools. The fact is that one of the most significant challenges to a service management approach is the cultural and organizational focus on IT silos to the detriment of enterprise IT management issues.
To explore this concept further from a tool perspective, consider your own organization and the following questions:
- Is there a defined enterprise IT tool strategy and architecture model?
- Is there any function or group in your organization that has a mandate to create and govern an enterprise tool strategy?
- Do you have a group in your organization that manages and supports IT tools that are used by IT functions across your organization?
- Are IT management tools budgeted for and purchased at a domain / departmental level, but are required to fit within a predefined enterprise strategy?
If you are like the majority of companies I have worked with, all of these questions would most probably be answered with a no and the resulting tool landscape would be filled with multiples and duplicates of various types of tools that do not integrate. It is also very common to find tool decisions for ITSM programs being made in isolation without the consideration of integrated tool requirements.
Lets face it we love our IT Management tools and each IT group want’s to have its own specialized set which they have exclusive control of and access to. This is true even though half a dozen other IT groups could benefit from its use given the opportunity. But for the most part we treat each other on a need to know basis and guard our departmental resources like misers, after all knowledge is power!
As a former geek I do love my Sci-FI and Star Trek has been part of my life since I was young. There is a famous quote by Spock in the movie “Wrath Of Khan” 1982 that comes to mind. “The needs of the many out weigh the needs of the few or the one.” Wouldn’t it be nice if this philosophy was a guiding principle for buying IT Management tools.
Troy’s Thoughts What Are Yours?
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” ~Bill Gates