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.