Yogi Berra, baseball’s great philosopher could have been the world’s first ITIL consultant. At least, in his own convoluted way, he expressed the frustration many ITIL practitioners have felt when trying to implement ITIL’s best practices; the theory looks good, but it just doesn’t work in practice.
I’m not saying ITIL doesn’t work, or its processes aren’t worth trying to implement. It’s just that when the empirical data is analyzed, there are not a lot of success stories around. To be quite honest, that has always bothered me since IT Service Management is really elegant in its simplicity. However, it’s not institutively obvious how to actually implement its processes. So the nagging question (as least for me) is why, followed closely by what can an IT organization do?
Conventional wisdom says that a successful ITIL implementation requires a thorough assessment of IT’s current capability, followed by the development of an ITIL implementation roadmap, lots of consulting and training; pretty much a standard “waterfall” approach to the structured design and deployment of the ITIL processes. I’ve successful used this approach to implement several core ITIL processes, so I know it works (at least sometimes).
However, some organizations are not culturally suited to a “big bang” highly structured mega program of “ITILization.” On the other end of the spectrum there are IT organizations that are so structured to almost to the point of petrification; they can’t seem to get anything done until the documentation outweighs the implementation team.
What follows is a “not so conventional” approach to process design and implementation that addresses each of these organizations; it’s what I call “Agile ITSM.”
IT organizations that successfully implement ITSM processes eventually achieve three different levels of capabilities; the first level achieves infrastructure and process stability and concerns itself with gaining control of the reactive processes of incident and problem management and the associated functional areas and the operational process areas of event, fulfillment and access management. The second level is optimization, or the capability to exert physical control over the infrastructure; configuration, change, release and deployment management. The third level is the capability to continually improve services and processes and includes service level, capacity, availability and continuity management.
A conventional approach to implementing all of these processes often fails to take into consideration the culture of the organization and its ability to internalize the structure, discipline and overall rigor it takes to follow a “waterfall” implementation approach. Often an IT organization’s culture is not prepared to adapt to a formal or “process-oriented approach to the delivery of IT services. An alternative method is needed to start the cultural change that will enable the IT organization to achieve the required capabilities as well as organizational maturity to become a service provider.
For IT an organization trying to adopt and implement ITSM processes, one alternative to a conventional “waterfall” approach is the use of “agile” methods, adapted to ITSM process design and implementation.
Agile provides a conceptual framework for software engineering. It came out of a meeting of noted software engineers in 2001 who attempted to rationalize a number of “light weight” methods for software engineering. The intent of “agile” was to produce software better and faster. For those of you who came of age in the software development environment of the 1980’s, it’s very similar to rapid application development.
Adapted for ITSM, its guiding principles are:
While it may seem like putting the inmates in charge of the asylum, this approach has proven quite effective in organizations where requirements are just being fleshed out and rapidly changing. Key success factors include:
If this sounds all “warm and fuzzy” it is, but it also has an edge to it. The whole idea behind “agile” and good ole “rapid application development” was that small, highly competent teams, working closely with their stakeholders can define, design, develop and deliver (implement) very rapidly improved processes. This is accomplished by limiting the scope of the effort and enforcing strict time limits to each round, or iteration of design, build and implementation.
This technique is primarily useful when an IT organization has a hero culture, but little or no tactical or strategic direction. The overall IT infrastructure and operational support process are unstable and the staff knows that life could be better, but not exactly how to make it better. The IT staff has a tendency to ignore structure or bypass process to “get things done.” A traditional “waterfall” ITIL approach will fail in this environment without wholesale replacement of staff. The “agile” approach leverages the skills of the “cowboys” and challenges them to become part of the solution – or face the only alternative in this case, which is to continue to live with the problem.
The agile technique is also appropriate in addressing the basic operational support processes such as incident and problem management because it leverages the technical skills of highly capable staff members.
Its usefulness will decline as both processes and the infrastructure stabilizes, and the need for more rigorous methods becomes apparent. However, at this time, both organizational capability and maturity will have achieved a level where a more rigorous approach is now culturally acceptable.
If an IT organization is not ready for change, and is not prepared properly for change, any effort to implement ITSM processes will fail (or not succeed). IT organizations are like living organisms with a built-in mechanism to defend against bacteria or change. Understanding the significance of the role of organizational culture and the need to manage organizational change as part of any ITSM implementation is key to achieving success. Adopting a more “agile” approach can kick start an organization down the change path by leveraging its own “undisciplined” approach and channeling it to morph the organization into a process-oriented, service provider organization.