Observations from service management tool change

Why the change – Needs and requirements?

Deploying new or introducing changes to the existing ITSM tool are demanding projects; the need for change should always be evaluated and understood before ‘kicking-off’ ordering or the development work. “A new tool is needed, as nobody is using our existing one” is a real statement but not quite an acceptable justification. It is very easy to become delighted by the exciting functionality offered by the various solutions out there, anticipating them to correct issues which are much closer to home. Stop, take the time to think and go back to the catch-phrase: people, processes-tools; technology should not be the only utilization driver. Poor tool usability, on the other hand, could be a problem worth investigating, but it is often difficult to distinguish perception from fact.

Large organizations create additional challenges in defining and agreeing to common tool requirements. Business units may have varying or even conflicting objectives. It has been noticed that having incident and problem management roles and responsibilities scattered across organizational units is particularly painful, leading to greater customizations, typically in both performance management and reporting areas. The corporate level view and benefit to customers are easily lost in the middle of all this. If in doubt, asking the question ‘is this change supporting our long-term objectives’, could lead the way.

It is obvious that tool changes must be aligned to support the realization and cascading of ITSM and business strategies. Building the modification plans on these will be a further guide in the business case creation; it will also help in narrowing down the key requirements from the initial vast array of ‘bells and whistles’. As an added bonus, change-management and getting the commitment from organizations will require less effort.

In general, organizations having a highly customized in-house ITSM tool with a high running cost, not fitting into operational requirements, or service management thinking, would have good reasons to consider a change.

Development and Implementation

As soon as the business requirements have been evaluated, prioritized and narrowed down, IT or ITSM tool management function is expected to implement the changes, usually with very short notice.

If the requirements are leading to customizations, this is a good reason to raise a warning flag. Hasty designs or decisions made without having the long term development roadmap in hand could result in complete dead-ends or very costly modifications in the next change. Thinking ahead and having proactive dialogue with the business is definitely worth the time and effort.

Close collaboration with all involved parties, should start no later than the concept phase and continue throughout development, testing and rollout. In following this, customer (business) probably gain a change matching their request and therefore also catering to the initial business need. Additionally, they have visibility and transparency in the development costs and they are engaged in the decision making regarding the design options, priorities and relevant investments. It is the very same idea and principle as Service Portfolio Management and its unrivalled benefits when budgeting IT Services.

Change Management

Tool change, like any other change project, is prone to failure without pursuing solid Change Management. At this point, another reference to Service Portfolio Management practices is worthwhile. Tool changes are not ‘just appearing’ in the daily operations either - transition phase requires a great deal of focus.

Communication is the key! Start it early, using different channels and media. Collaborative workspaces are good places to raise awareness. Active Q&A sessions with communication skilled experts, providing prompt answers, will prevent the rumors and negative perceptions spreading. In addition, proper user training and the effort required must always be part of the plans.

In complex, global matrix organizations, ordinary one-way communication is not enough. Be prepared and expect different lines of matrix having other priorities or even objections. Minimal commitment is typically characterized by conflicting operational targets and incentive schemes, most often in the resource area. I have seen line management rejecting tool user’s attendance in training sessions, simply because it would deteriorate the local resource utilization ratio.

This is hard to tackle without knowing the organizations and their working cultures. Seek out opinion leaders and stakeholders, approach them, discuss and justify the upcoming change effort and get a commitment. Lobby, lobby, lobby and use inside supporters, if necessary. Do it from very top down; executives will support and cmmit to the change if it is aligned and part of the corporate business strategy.

Can it be done?

Challenging? Oh yes, but not impossible, it requires proper planning, understanding of requirements, collaborative development, solid change management and experienced professionals. It can be done, I have seen it…

Heikki Seppänen
3gamma Finland

If you’d like to know more about how 3gamma can help your business get the great IT it deserves, contact us now.