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

By Laurent Duenas, June 4th 2013 

 

In Part 4, was presented a structured approach in order to build a solid ITSM project plan. In Part 5, we address the process and tooling formalization steps. Then, in a conclusion, the stakes of an ITSM project are detailed.

 

3rd question: which approach enables me to deal with these questions in an exhaustive way? (suite)

 


Stage 4: Formalization of processes ((iterative at each maturity level)

From this stage onwards, the framing stage is over. The project enters an operational stage.


The formalization stage aims at formalizing processes, often through flowcharts with general and detailed specifications. This stage is also called design stage. It is often considered as the project highlight. In this case, it can turn out to be a real danger because little effort is deployed for the other stages which are just as important.


First of all, the notion of formalization (as drawing the process flows) should have educational purposes. Formalizing processes adapted to the organization certainly is a goal, but should not be the only one. On the one hand, because to start with, processes were already formalized in many organizations and books that you just need to consult. Moreover, focusing mainly on this, you often get bogged down into too many details, which makes processes little flexible and bureaucratic. On the other hand, because this stage aims at progressing together with key stakeholders (« influencers »). It is essential to constitute a strong team of project « supporters », a necessary lever if deployment is to be successful (to forecast in “Leading Change” plan).


The ITSM project manager must also bear in mind that formalization includes the design of all elements part of process operation: management rules, indicators and management reporting, procedures (at least listing them is required), data repositories used, and sometimes even organizational aspects. All of these points are part of the best-practices integrated into the projects defined in the maturity levels of the Implementation Plan..


Main activities are:


► Launch of the ITSM project specific to a maturity level (with all stakeholders)

► Animation of process formalization workshops (activities, stakeholders, management rules, deliverables, KPIs)

► Organizational evolutions required

Modeling of the various forms, data models used in the process

Identification of the tools used and assessment of their added value to support the process

Identification of the procedures to formalize (type, nature)

      

Stage 4a (iterative at each maturity level): expression of tooling needs (in parallel with process formalization)


During the process design stage, numerous tooling requirements can be collected, a good opportunity to set up specifications. Only at this stage, it is most relevant to consider implementing a tool. Sometimes, for various reasons, tooling becomes the spearhead of ITSM projects. It is up to the project manager to attempt maintaining coherence between the various parts of the ITSM project (management, processes, organization, culture).


The approach consists in writing specifications (some of them being technical) that translate tooling needs into functionalities expected from the solution. In order to better understand expectations, specifications can be attached to the definition of the final purpose and conditions of use. This solution is supposed to stick closest to organization objectives and priorities. Consequently, specifications are prioritized depending on whether they are imperative or not. The technical and operational context of the future solution (environment, volume, etc.), as well as technical and organizational constraints, generally complete the bill of specifications. To further help choosing the tool, specifications are prioritized and/or rating scales are set up to weight responses according to their importance.

Main activities are:


► Collect tooling requirements

► write specifications (functionalities expected)

► prioritize specifications ("must have", "nice to have", etc.)


Stage 5 (iterative at each maturity level): implementation of process (and tooling)

Process (and Tooling) Implementation is the most concrete part of the ITSM project. This is actually the time when concepts start becoming effective and deliverables turn out to be efficient or not. It consists in implementing all the best-practices designed in the workshops at the previous stage: implementing activities, applying new principles or new rules, using new supports, new frameworks, etc.,


The implementation stage takes shape in various ways: workshops (vision sharing, principles presentation, even evangelization), field support (coaching of activities), individual coaching (for managers), follow-up and result reviews, etc.


This stage itself breaks down into various substeps: a pilot stage (on a limited scope, aimed at validating the best-practices implemented), then one (or several) more or less progressive diffusion stage(s).


The implementation stage is subject to particular attention from project management. The change management schedule focuses a lot of its efforts on this stage.

Main activities are:


► Briefings

► Field support, leading, coaching,

► Trainings

Follow-up and result reviews

Reporting about progress


Stage 6 (iterative at each maturity level): intermediate evaluation and project wrap up

Each level wrap up - this is valid until the end of the project - gives the opportunity to evaluate the progress made by the organization, and possibly, to demonstrate the benefits obtained.


These evaluations follow an approach which is similar to the initial maturity audit at stage 1. The assessment questionnaire and evaluation criteria can be reemployed. The scope must be adapted. The approach can be simplified because the maturity level reached only focuses on a part of the best-practices implemented. Keeping the same approach brings a constant (and normally more relevant) structure to measure progress. However, what is essential is to assess contribution to business objectives identified at stage 1. But often, this measure is more delicate, because it requires assessing the real contribution to business results, bearing in mind the side effects of other actions launched by businesses themselves. For this purpose, it is essential to set up the mode of assessment of this contribution as early as stage 1.


Whatever the result obtained, it is essential to share it at each iteration with all stakeholders. It is also essential to give them conclusions and decisions for the future. Because with IT Service Management, every project has a continuation; what is at stake is continuous improvement. This opportunity for project managers, team managers and teams themselves to meet, allows to better understand together the difficulties specific to the organization and to better understand future windows of improvement. This is the opportunity to present the objectives of the future plan, adjusted with the necessary improvements. This feedback, which can be enhanced with a cocktail of incentives, or even with other festive activities, is a way of keeping the enthusiasm of stakeholders (and the momentum) to continue towards the next level.


Main activities at this stage are:


► Assessment of acheivements made

► Assessment of benefits obtained

► New positioning on the maturity scale

Feedback about the level reached

Definition of the future actions (adjustements at next level)

Celebration and recognition of efforts


Conclusion: Be aware of the risks of an ITSM project

This article does not address all the possible difficulties of an ITSM project. Many other major topics should be explored, such as: modes of formalization and their impacts on process use: setting and development norms of ITSM tools in order to keep developing them at the lowest cost; content of change management schedule, etc.


This article voluntarily focuses on the 3 objectives that are deemed structuring for an ITSM project: aligning best-practices on business objectives; being consistent in their selection and planning; having an ITSM project approach that includes these concerns and is able to control them.


Without vision or coherence, the project can produce results totally disconnected from business objectives; totally lose stakeholders buy-in and motivation since they see no improvement in the situation before and after; swallow high investments without concrete results or with documents of principles that are not applied. To make it clear, the risk for an ITSM project is to be useless.


“What struck me frequently was to see the weariness of customer teams having to deal with the ambitions and efforts required by ITSM projects. Stakeholders are often tired of participating in workshops where endless jousting takes place about formalization, without really addressing their concrete concerns”.


It is essential for an ITSM project to include a clear vision guiding stakeholders: this essential federative vision capable of launching a dynamic on subjects they do not believe in any more. I insist a lot on the “non technical” nature of ITSM projects, because what it is all about is cultural change.


This article will not address all the topics which turn an ITSM project into a success. Of course, a large amount of “steering” is the key to success. But at first, for the project to be successful, the ITSM project manager must be able to « build a federative vision » and to « identify the progressive approach stakeholders will accept ». He should not ignore these essential topics.



(End of the article)

Copyright © 2013 - PRACT Publishing