Is the approach of ITSM Project as strategic as its objectives (Part 2)
By Laurent Duenas, June 4th 2013
2nd question to ask: how to make implemented best-practices consistent?
Which best-practices should be implemented? What should be integrated into an ITSM project? Selecting and planning is a must. But on which criteria?
The purpose of this article is to thoroughly examine the actual objectives of an ITSM project and the various approaches to reach them. Of course, we know all about maturity audits, process formalization stages, but in the end, do IT stakeholders have a full vision of the issues an ITSM project should address and on how to get there? The author leads us into the core of the ITSM project addressing its challenges, its difficulties and the founding principles which are essential to the construction of an efficient and successful project.
This chapter deals with two major types of inconsistencies:
► Inconsistency in the best-practices implemented compared to the objective set up.
It can show up in the choice of the best-practice itself, but also (and very often) in the time chosen for its implementation.
► Inconsistency in maturity levels among various implemented best-practices.
Often, best-practices can be implemented in an iterative way, with increasing depth levels. So it is important to make sure each iteration embeds the ones whose maturity levels are consistent.
Chose best-practices in line with objectives targeted
When starting an ITSM project, companies often tend to implement a whole process. This is normal, especially when they discover the universe of ITIL V3 framework processes. But a process in itself, as well as all the best-practices it draws, meets several targets at the same time. This is an area where choices can be made, regarding both the nature of best-practices to implement and the depth of their implementation (see 3rd item in this chapter).
Let us take the example of an ITSM project for the implementation of Problem Management within an organization, whose priorities are to reduce its IT expenditures. The implementation of Problem Management brings along many best-practices, among which a selection can be made to stay in line with cost reduction objectives:
Some best-practices can turn out to be quite heavy
In the absolute, it is undeniable that some best-practices can be useful, and have to be integrated into the ITSM Project plan. But according to the way they perceive these practices, companies can inflict themselves obligations which can finally turn out to be very expensive. To illustrate this point, I am going to take the (very common) example of CMDB.
We often hear that a CMDB is indispensable to most processes, and must be implemented as early as possible in an ITSM project. In the absolute, this is not wrong. But when you consider what is required for a CMDB to be able to supply useful information about process activities; and when you assess the efforts required to get there; it is quite normal to wonder whether this CMDB should not be implemented later within a dedicated project? And the question is fully justified.
The following are often key points you discover on the fly, once you have embarked « headlong » into a CMDB project:
► Building the database model requires an accurate vision of usages and a consensus from all contributors and data users (which takes several months),
► CMDB feeding relies on sources requiring clarification of responsibilities between data owners and repository administrators, as well as reconciliation and consolidation rules, which require in depth study about how to proceed and about their impact,
► CMDB (or rather CMS) tools supply interactive quiry or report functionalities, but their results are difficult to use as such. For example, beyond a given volume of implemented data, graphic views show « spaghetti plates », totally inoperable to allow Service Desk diagnosis. Very quickly, it becomes indispensable to set up a method to operate the CMDB and to create supports (graphic views, reports) to structure analyses or diagnoses. This method requires time and buy-in,
► After CMDB operational delivery, process activities must also widely use CMDB data, failing which it becomes useless and quickly obsolete. Processes often even failed to include the very use of the CMDB. They must be revised and stakeholders supported throughout the change process.
The example of the CMDB alone shows that its implementation must be conceived in a progressive and iterative way. ITSM projects must progressively embed best-practices and target clearly identified objectives per iteration.
Some best-practices can be implemented from the start and some others cannot. It is possible to start a Change Management process or an Incident Management process without really launching a complete CMDB project, even without any project at all. Processes will be limited to the repositories that are essential for users or the existing equipment fleet (without real federative project such as CMDB). All this simply aims at reaching ITSM project objectives, without falling into a « tunnel effect ».
And this example is not limited to CMDB. Other examples exist in other processes:
► Release Policy in Release and Deployment Management process
► Repository of availability norms and standards in Availability Management Process,
► Test models to implement in Test and Validation Management process, whose results are successively used in Evaluation Management process, and then in Change Management process,
► Capacity Management (Business/Service) consumption models, allowing to turn business and IT Service consumption units into technical resources consumption.
► Service models in Service Strategy,
► Users Profiles and Patterns of Business Activity in the Demand Management process,
► No link
► No link
► No product
Copyright © 2013 - PRACT Publishing