Making ITIL real: Change Management for Technology Adoption
Wishing that ITIL was real? Read this!
Don’t you wish ITIL was more, somehow, real? Real as in really about IT Infrastructure, and not some tripartite God-like structure of People-Process-Technology (just why is technology last, anyway?).
In a previous post about ITIL is about Technology Adoption, I talked about how you could use ITIL your advantage if you thought of it as a series of barriers to overcome in technology adoption. A simple formula might look like this:
Business Value = Technology Adoption + Overcoming ITIL Barriers
Show is much better than tell so here’s an illustration of how you can overcome ITIL’s Change Management barriers to succeed in technology adoption. This is an illustration, not a complete guide (ping me direct if you want that!).
Overcoming the Change Management People Barriers
The first barrier to your technology adoption is a virtual team called the Change Advisory Board. They are going to refuse any changes for your technology, and seriously hamper your technology adoption, unless you do certain things:
- Join their team: you need a rep on their team.
- Translate the details of your technology into the ITIL lingua franca: categorise the changes you are likely to make into Standard, Normal, Emergency language.
- Schmooze: as well as joining the team and talking their language, you’ve got to make them feel safe and secure. I’ll leave the methods up to you, but make sure to include “education” amongst the beer and peanuts.
Outside of the CAB are lots of “hangers on” who are just itching to say “No” to any of your changes. Again, you have to make these people feel secure by talking, showing, empathising… think internal marketing.
Overcoming the Change Management Process Barriers
Somewhere on a wall in your company is a big process chart. It won’t make any sense to you because it’s been written in a special religious language called ITIL. Only priests of the itSMF can interpret it for you (think Bible before King James and the printing press).
You need to get someone (a change manager) to explain the process to you and work out how to fit your technology into it. This will result in you having to add money to your budget to fund the effort of fitting in to this process. If you don’t fit into the process, you will be in the Dog House: everyone will point at you and your technology and call you A Risk. And the guys that pay the bills don’t like A Risk.
The best way to get over this is to make sure you are doing the following things:
- Create something called a Change Window and only let your staff make changes in that window. You can have as many of these as you like, but best to schedule them when the service can take it. If you’re using VMware ESX then that can be any time in the day thanks to Maintenance Mode
- Enforce the Change Window: Make it well known that if anyone makes changes outside the change window they will be publicly named and shamed and even disciplined, including moving jobs (including out of the door) if it persists. This tells everyone in Change Management that you are a Good Guy.
Overcomming the Change Management Technology Barriers
The change management guys, despite being itSMF priests, do use technology. They probably have something called a Ticketing System that changes are recorded in. Here’s what you need to do:
- Put your tech in the change tool: Make sure your technology has a code that changes can be assigned to. Make sure you are the owner and can see, approve, authorize, reject etc. all changes against your technology.
- Put some change templates into the change tool with help from Change Management. This helps them do their job with their tools and elevates your Good Guy status.
Put it all together and…
You are effectively removing any barriers that the change management team can put in your way. You need to keep working at this, making sure your team make changes in a repeatable, documented manner.
Do this, and your technology adoption won’t be hindered by change management. A bonus is that your technology will also be effectively change managed and you are on the road to being a high performance IT organization. Another bonus is your profile has been elevated from A Risk to Good Guy. Well done!
Related posts:
Stevey,
I rarely post comments on your posts, being bleeding edge I stick to the medium of Twitter for direct responsive feedback
, on this occasion I wanted to add some comments and views on this post.
Excellent post that this is, based on what you’ve written does the CAB really in your experience of working with multitudes of big organisations with the full ITIL Shebang implemented create barriers to adopt new technology?
The CAB maybe the barrier on any new adoption of changes ONCE its deployed but I would sincerely hope that anyone investing in such new tech would be good enough to have a top down strategic approach to educate and align the processes with whom it may concern. Additionally Architectural roadmap and strategic vision is always one step ahead of the CAB if the structure is in place for this to happen.
Maybe the issue with adopting new technology into processes isnt so much the CAB themselves…..but the responsible people who’s job it is educate such example areas of IT?
I absolutely see top-down approach, but it’s strength dwindles like the ripples on a still lake after a stone has dropped in it… I think this is where barriers become difficult when enough people ask “why should I?” then the energy is sapped from the technology adopters and solution providers and you either get a warped solution to fit unagile ITIL processes AND/OR failed project / unrecognizable end result.
I’m with ya dude!