Lessons Learned from IT Service Management Tool Implementation: Part 8

 Eighth in a Ten Part Series

By Chad Greenslade

I have often been asked about my lessons learned in implementing an IT Service Management (ITSM) tool.  Below is the eighth in a ten part series examining my ITSM lessons learned.  I hope that these lessons help you on your journey to ITSM nirvana.

Lesson #8: Resist Customization.  Everyone thinks that their organization is unique, has a unique use case, and has a valid reason why a tool should be customized to fit their use case.  While I am not denying that there are some valid reasons for customization, implementing an ITSM strategy should largely be based on ITIL.  If your organization is doing something that doesn’t conform to ITIL, it’s probably worth examining the non-conforming activity and attempting to discontinue it.  Anyone that has been in IT long enough knows that customizing commercial off-the-shelf (COTS) software will undoubtedly introduce unknown complexity in the future.  The software manufacturer and the integrator may warn you against customization while simultaneously advising that the customization you are requesting is both doable and won’t cause a headache later.  Again, beware; they are attempting to sell you a product.  Think long and hard about any potential customization.  It will cost you in the future in terms of additional custom development in order to implement upgrades, as well as subsequent pre and post release testing. 

Lessons Learned from IT Service Management Tool Implementation: Part 7

Seventh in a Ten Part Series

By Chad Greenslade

I have often been asked about my lessons learned in implementing an IT Service Management (ITSM) tool.  Below is the seventh in a ten part series examining my ITSM lessons learned.  I hope that these lessons help you on your journey to ITSM nirvana.

Lesson #7: Review ALL existing ITSM systems, organization charts, and IT contracts when developing the strategy for your new ITSM platform.  If you’re going to deploy a new, single, unified ITSM platform to replace all others in the organization, you’ll need to gain read-only administrator access to each of these existing systems and thoroughly interrogate them.  This includes project management systems.  Any application that is used to manage IT assets (assets are hardware, software, and people) should be reviewed and a thorough analysis conducted to determine exactly how use cases will translate from existing systems to the new one.  Similarly, you’ll need the organizational structure context that only organizational charts can provide.  While the transition is under analysis and execution, a concerted effort must be made by the organization to keep reporting relationships and functional teams largely intact.  In other words, it becomes increasingly difficult to implement an effective ITSM strategy if the organization is in a constant state of flux.  Lastly, you’ll need to gain access to all of the active asset (underpinning) contracts within IT.  When implementing asset management and service level modules, the information contained within the contracts will be required.  Some of this information may be sensitive so be prepared to have these conversations with the keepers of these documents.