7 Enablers for ITSM Expanded - Ability To Deploy

Designing An ITSM 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

Like this article? Like

Comments

Post a comment