You've decided to commit to ITIL. Or you've decided to think about committing to ITIL. A commitment to ITIL v3 is a commitment to continual improvement. This means you are taking a journey, not achieving a one-time goal.
But given the span of what ITIL v3 covers, this can be a daunting task if your organisation traditionally has a buy, deploy, break, fix mentality. As you move down the path to adopting an ITIL v3 culture at your company, there are three major areas of concern that you need to be aware of:
Overcome internal objections: Your internal team can potentially be your greatest ally or your biggest detriment. As CIO, you need to put together a sustaining project plan that your staff can embrace. You'll also need to address some of the following adoption objections you'll face:
ITIL v3 is too big. The initial objection you'll hear to ITIL v3 is that it's too big of a beast to handle. However, a sensible project plan can identify key services you can address with limited implementation of ITIL v3. For example, target a low-risk environment within a critical service as a good starting point to implement (or upgrade existing) service management processes.
ITIL 3 is too complicated. The coverage of ITIL v3 is fairly comprehensive. As such, those people currently in IT management may look at its broader picture and consider it outside their knowledge, experience or responsibilities. It is important for the various constituents involved to understand that the essence of ITIL v3 encourages the cross-department cooperation in achieving business goals (better service, customer loyalty, increased amount of new/improved services, lower per-cost services, etc.). IT organisations need to provide value to the business; otherwise, they can be outsourced at a lower cost.
ITIL v3 is too costly. If not driven in a stepwise approach as described above, with targeted milestones and benefits that can be obtained in a low-risk manner, the cost in time to implement ITIL v3 practices might look outrageous to many CIOs. Additionally, the various software and hardware products used to deliver a solid ITIL framework often overlap, conflict or act as "islands of information" (see vendor misdirection, below).
Observe internal behaviours: In many companies, the IT management groups are split into different technology disciplines and often separated from the various critical application groups. This is a traditional approach that still permeates many corporations today. The CIO should work to break through these barriers and watch for the following behaviours:
IT management is conflicting with application management. In so many companies, this conflict is the most common and creates the biggest problems, which often leads to service disruption.
Imagine this scenario: an application group maintains its own network and servers, which were purchased through the corporate IT group. Due to the nature of the application, the group maintains its own change-and-release management processes. The corporate IT group, however, has governance requirements it must meet to maintain security adherence to regulations. The application group's servers are linked to the corporate network, but fire-walled from incoming traffic. To meet the corporate security policy, an IT manager in the corporate IT group has disabled the firewall and downloaded a security patch to the application group's servers. This causes the application to crash and disrupts a multimillion-dollar production process, causing it to fail. Millions of dollars are then lost due to production failure and supply chain disruption.
When deploying ITIL services, CIOs need to collaborate with boundary groups -- such as security management, change management and network management -- to devise policy and processes that support application needs while avoiding noncompliance.
IT and application management have conflicting or overlapping tools. Again, many application groups are separate from corporate IT groups. In numerous cases, application groups obtained and deployed specialised IT tools for their critical system needs that were different from those of the corporate groups. This inevitably leads to islands of information and processes, which are not conducive to deploying an ITIL framework. Everyone does not need to conform to the same tool sets, however policies and processes must be worked out in a collaborative manner to eliminate this concern.
Keep an eye out for vendor misdirection: If you listen to IT management tool pitches, you'll learn that software comes in three categories: tools, tool suites and architectures. Here are some tips for selecting the appropriate vendor and IT management tool:
Your needs will vary for tools. There are a number of great network management, virtualisation management and performance management tools available, depending on your specific needs. However, policies and processes must be worked out in a collaborative manner to create a solid ITIL v3 environment.
Integrated product suites are now available. Most of the larger vendors are attempting to create all-encompassing product suites. Here is a list of questions you can use to evaluate the critical features of any integrated product suite:
Can processes be modelled as unique across families, types, or even individual configuration items? How about service-level requirements?
Are service containers not only modelled, but also used in correlating events?
Can end-to-end, cross-network, cross-facility transactions be monitored?
Does configuration tracking support event correlation?
Is it easy to trace an IT management process from start to finish (e.g., incident -> problem -> known error assignment -> change request -> release -> change -> configuration)?
Does the process modelling support governance reporting?
Evaluate various architecture-based product suites. Many large vendors are promoting application servers, Web services, service-oriented architecture, enterprise server bus and other supporting middleware as the "glue" for integrating the various IT tools in their products. While it is important to have a flexible infrastructure, make sure the focus remains on delivering value when selecting an architecture-based product suite.
Whether you need new tools, tool suites or complete architectures, choose wisely. Find and visit reference sites and ask hard questions. And remember: The goal is to help drive business value, not be a cost centre.
ITIL v3 is not a static objective; it is the start of a journey.
In the last few years (and in Europe even longer), IT management has journeyed down the same path. Corporations are actively striving to move IT management into the realm of driving business value and supporting competitive advantage. Moving toward a holistic vision of ITIL v3 provides that path. The objections, behaviours and vendor issues that CIOs face with ITIL have been overcome before. Keep in mind, however, that ITIL v3 is not a static objective; it is the start of a journey.