Tuesday, December 29, 2020

Lessons Learned from IT Service Management Tool Implementation: Part 10

Tenth 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 tenth in a ten part series examining my ITSM lessons learned.  I hope that these lessons help you on your journey to ITSM nirvana.

 

Lesson #10: Pilot your new ITSM platform in parallel with your old “ticketing” system.  There is no better way to understand how your new car will operate than taking it for a test drive.  ITSM platforms are no different.  You’ll want to run at least part of your new ITSM platform in parallel, in a test environment, prior to a production cutover.  This will undoubtedly cause increased burden on Service Desk and technical staff as they now have to log and work Incidents in two (2) systems.  Unfortunately, this is a necessary evil whose risk management rewards far outweigh the one-time additional effort. 

Friday, December 18, 2020

Lessons Learned from IT Service Management Tool Implementation: Part 9

 Ninth 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 ninth in a ten part series examining my ITSM lessons learned.  I hope that these lessons help you on your journey to ITSM nirvana.

Lesson #9: Have a good CAB.  ITIL will tell you that the “Change Manager” is the only person that needs to approve a Request for Change (RFC).  While this is literally true, the “Change Manager” must be advised by someone.  That “someone” is the Change Approval Board (CAB).  In reality, however, most ITSM platforms and organizational practices require the actual approval (recorded in the ITSM) system of many different stakeholders.  What you want to avoid is folks who provide “rubber-stamp” approvals.  You want approvals to be meaningful and reflective of a person’s true position of authority in the organization.  Similar to the way some organizations skip the step of defining services or a service catalog, many organizations will take shortcuts in defining who should approve an RFC.  As I mentioned in Lesson #5, every service and CI should have an owner.  When an RFC is raised and the requestor of that RFC selects the services and CIs that are impacted by the RFC, the owners should be notified by the ITSM tool that a new RFC has been raised against their service or CI and that their approval is required.  In my professional opinion, these are the only three (3) persons that should approve an RFC; the service owners, the CI owners, and the Change Manager.  I fully endorse the concept of the CAB advising the Change Manager, but approvals from CAB members are not necessary.  

Thursday, November 26, 2020

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. 

Monday, November 9, 2020

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.