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.  

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. 

Lessons Learned from Agile Transformations: Part 1

First in a Fifteen Part Series

By Chad Greenslade

 

I have often been asked about my lessons learned in delivering Agile transformations.  Below is the first in a fifteen part series examining my lessons learned while instituting Agile concepts & practices.  I hope that these lessons help you on your journey to Agile nirvana.

 

Lesson 1: Identify the Agile Sponsor & Champion

 

Before you start your Agile journey, you must identify a Sponsor or a “champion” from the ranks of the executive team.  The Sponsor will be similar to the captain of a ship.  You will work with this person to define the destination and ensure the “ship” (the Agile transformation effort) is on the right course.  The sponsor will keep the larger executive team up-to-date on a regular basis.

 

In order to identify a Sponsor, you’ll want to find someone that is involved in several high-profile, important initiatives within the company.  You’ll want someone who is approachable and understands the importance of relationship building.  You’ll also want someone who is familiar with, and has influence over, gaining the funding you need to make the transformation.  Finally, you’ll want someone who identifies the fact that the transformation you seek won’t happen without training the folks involved in the transformation and is willing to throw his / her support behind an Agile education initiative.  Your Sponsor will be tasked with selling the need for proper training for both the teams executing the Agile practice and the executives consuming the Agile product.

 

Your Sponsor will be the organization’s representative for the transformation effort.  You’ll want to work with this person to establish tenets of the transformation vision and clearly articulate why the organization is undertaking the initiative.  The development of “talking points” and “elevator speeches” will be critical to effectively allay concerns of folks involved with, and affected by, the initiative.

 

The Sponsor will be the person that removes the “roadblocks” encountered during your journey.  For this reason, it’s important to select a person who is comfortable with people at all levels of the organization.  The Agile transformation team must be comfortable with sharing honest and open feedback with the Sponsor and requesting his or her assistance in accomplishing their objectives.  Like any good leader, your Sponsor must possess active listening and follow-through skills in order for team members to feel heard.  The Sponsor does not have to be a “technical” person but they should have a firm grasp of the delivery process.  The Sponsor should be universally regarded as a leader throughout the organization and someone who has the influence, not necessarily the power, to get things done. 

 

Lastly, it’s critical that the Sponsor have a firm grasp of the “big picture” and understand the cultural mindset shift that must occur.  Prior organizational rewards mechanisms may need to be changed in order to properly incentivize people to make the changes necessary.  It will be important to measure the transformation effort against established success criteria and publish successes, or setbacks, as required via development of necessary publication materials.  Open recognition and publication of successes is critical to boosting team morale and enforcing the change that you need in order of the transformation effort to be successful.