Is the approach of ITSM Project as strategic as its objectives (Part 3)

By Laurent Duenas, July 6th 2013 

In Part 2, have been presented the criteria helping to make the right choice of best-Practices, based on objective alignement and acheivable targets. In this article are discussed the inconsistencies due to Best-Practices selection within a same stage of implementation.

2nd question to ask: how to make implemented best-practices consistent? (continuation)

Make Best-Practices coherent

During the implementation of a stage of an ITSM project (because we now know that it will progress in an iterative way), best-practices must be selected according to a homogeneous depth or maturity level.

Let's take the case of an ITSM tooling. All organizations know situations showing gaps between the functionalities offered by the tool and the required ones relevant to the principles defined for the process (es). This gap concretely results in fields, functions, categories, workflows and rules, available in the tooling, which are actually not justified considering the process’ (es’) objectives.

The following example of the tool supporting the Incident Management process illustrates this situation frequently observed within organizations. From the beginning the project is often not properly engaged due to incorrect approach:

► New tooling choice is made before any consideration about the process.

► The project manager has a pure technical background, with poor Service Management experience

► Process requirements are not adequately defined (insufficient scope, unsuited granularity, etc.)

No adequate contributors from stakeholders part are involved in the requirement workshops.


This example, far from being isolated, leads us to the following considerations which can have impacts on the quality of the service delivered:


Of course, all of these remarks must be repositioned into their context and not be taken as general information. But preconceived ideas also cause havoc within organizations.

Cases of inconsistency do not only exist between processes and tooling. Inconsistencies can potentially exist within a set of rules in a same process. Let's take the example of the Release and Deployment management process. There too, the story starts with the wish to implement a Release and Deployment Management process closest to the recommendations of the ITIL framework. But ITSM project manager’s knowledge of the overlaps and intersections with the Change Management process is often not thorough enough. Principles, rules and other process formalizations result in being disconnected from the reality of the organization, which is quite unable to put them into practice.

There too, some facts are strikingly true:

The cost of inconsistencies

You cannot address the possible inconsistencies of an ITSM project without mentioning its cost. You have to face it: an ITSM project which does not reach its objectives can swallow a significant amount of money.


As a matter of fact, for several months, an ITSM project requires a management team; invests in training; needs consulting for guidelines and change management; buys tooling (including a significant number of licences) - even pay-per-use approach represents significant budgets. Finally, it mobilizes operational teams for all build and then deployment stages, which impacts their productivity in their day-to-day activity and finally turns into a loss.


So, an ITSM project which does not give tangible results applicable within the organization after several months, even years of effort, which does not significantly and verifiably contribute to business objectives, simply turns out to be a genuine financial disaster amounting to several hundred, even million dollars.


That is why on the one hand, an ITSM project must be rigorously driven by its project manager just like any project would be, and also be a Project Management Office, to permanently check that middle objectives are reached; but on the other hand, it must imperatively be guided by a clear vision of objectives alignment on business objectives and consistency in the selection of best-practices to do so.



Copyright © 2013 - PRACT Publishing