Organizations are eager to improve the effectiveness and efficiency of IT services. The IT Infrastructure Library (ITIL) has much to offer with its IT Service Management (ITSM) philosophy and reference processes. The challenge that groups face when implementing ITIL is that the process must be tailored to the needs of each organization, and it is critical that it's done correctly. As a result, many ITIL projects either stall or outright fail. Herein lies a challenge: How can these projects recover?
First, recognize that recovery takes work -- hard work. When an ITSM implementation fails, it risks being viewed as another management fad that hasn't lived up to the hype. This makes recovery much more difficult, because in order for the next attempt at ITSM implementation to succeed, employees must believe it will be successful. Moreover, the next time around must be successful. Three strikes are too many for a failed ITSM implementation.
For groups that have either stalled or failed (and most stalled projects become failed projects), the following suggestions can help you understand what happened and potential corrective action.
Candid feedback
The first step is to understand what went wrong, and there are two methods here. The first is to honestly ask those involved, "What went wrong?" and "How can we prevent this from happening again?" Some groups do so internally and are successful. Candor is critical, and unless people can talk freely, the discussion won't be effective.
The other method is to bring in an external group to assess your organization's current state. The assessment will review processes as well as identify problems that occurred during the failed ITSM attempt and gaps between a company's current state and its future goals. From this analysis, an implementation roadmap should be created.
Some groups split this process into two phases. The first aims to understand what caused the last initiative to fail, and the second is to understand the current state and create a roadmap based on business needs, constraints and so on. Again, different groups need different approaches.
Understanding is an important first step. But you must go further and establish how to prevent these obstacles from affecting your next attempt. Use a core team of people and work through each obstacle, identifying the root cause and at least three options for preventing it next time. It is critical to address the root cause and not stop with superficial answers such as, "We didn't communicate enough."
How does ITSM aid business objectives?
It is critical that the ITSM initiative is clearly linked to the goals of an organization. IT provides services that enable other business units (such as customer service and manufacturing) to create and protect value. Process improvement efforts that do not support and protect an organization's goals are wasted efforts.
To illustrate, imagine a chain with a weak link. If all the other links can handle a load of 1,000 pounds but the weak link can only handle 500, the overall capacity of the chain is limited to 500 pounds. If we spend a million dollars improving every link on the chain to be able to lift 2,000 pounds but the weakest link is missed, guess what? The chain can still lift only 500 pounds despite that investment.
We see this phenomenon in business and IT all the time at both the strategic and operations levels. Resources are limited and must be deployed with precision. Process improvement must be architected to yield real benefits -- not hoped-for benefits.
Companies with challenged ITSM implementations need to ensure that planned processes indeed help the organization by creating and protecting value. The project team must clearly communicate the details to senior management and other stakeholders. It is critical that people understand this causality and make appropriate decisions.
Organizational change
When improving IT processes, remember that an organization must adjust to actually use them. All too often, organizations rush out and buy ITSM tools from a zealous vendor, install them and wait for the world to change. The tools are used nominally, if at all, and the hoped-for benefits don't necessarily materialize.
Many IT groups fail to address the "soft" issues of organizational change and see their ITSM efforts fail. What's more, a restarted ITSM initiative often faces a more difficult climate than an initial effort. For this reason, it is critical to factor in what is needed to change the organization. Consider the following cultural elements:
- Tone from the top. Senior management needs to support the effort in words and deeds. The first time they say, "Just get it done and ignore the new processes," will result in tremendous damage. Conversely, strong support from the top down can greatly benefit and reinforce organizational change efforts.
- Core team and extended team. One approach to implementing processes is to use a core team that is involved with all aspects of process design and then a formally defined extended group that is used as necessary. The intent of this approach is to stay small and focused during the design efforts but to involve get input from stakeholders as needed and to leverage their personal networks to facilitate change. Both groups will be vital in terms of evangelizing the changes.
- Communication. Good communication is needed throughout the process improvement effort. People need to understand progress made, key decisions, how the changes will benefit the organization and so on. In the absence of information that is adequately communicated, people fill the void with conjecture, fear and other detritus. A formal communication plan must be developed to keep people informed in a timely, efficient and effective manner.
- Training. Training is a key element to organizational change. Developing policies, procedures and tools in a vacuum and then telling people to change isn't sufficient. People have many learning styles, and training programs can help overcome fear and improve the likelihood of success by helping employees understand how to perform their new roles. Formal training plans should be developed and executed to maximize benefits.
- Compensation and metrics. These need to align with the new processes and support efforts. Sometimes teams do not address these issues, and the result is that personnel are pulled back into performing their jobs the old way.
- Pilots. Pilots are often skipped despite their incredible value. Pilot implementations allow ITSM project teams not only to test new processes and technologies and make last-minute changes but also to demonstrate that the new system really works.
- Phased implementations. A phased implementation can improve organizational change in situations where the rollout of new processes and technologies can be gradual. First movers should be based on their willingness to change, the political climate, business needs and so on. Similar to pilots, phased implementation allows for the use of new policies, procedures and technologies and also allows time for their evolution. Each successful rollout will not only make the next deployment easier but also foster a desire among other groups to adopt the changes.
Project management
Last but not least, project management is necessary. ITSM is not something to pursue ad hoc. The rigor of formal project management -- an identified project team, approved budget, tracking of tasks, reporting of progress and so on -- are exactly what is needed to oversee the design and implementation of processes.
Groups that do not have project management in place should consider the approaches from Projects in Controlled Environments version 2 or the Project Management Institute's Body of Knowledge, depending on which is the standard in the given region.
Conclusion
Despite the best intentions, ITSM implementation efforts can stall or fail. To recover from a failed initiative requires an understanding of what caused the failure through frank discussions and the identification of root cause. ITSM project teams must then formally plan their projects to overcome obstacles and succeed in ITSM implementation.
ABOUT THE AUTHOR: George Spafford (http://www.spaffordconsulting.com/) is a principal consultant at Pepperweed Consulting and an experienced practitioner in business and IT operations. He is a prolific author and speaker and has consulted and conducted training on regulatory compliance, IT governance, and process improvement.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
