ITIL Change Management process is about maximizing control and minimizing risk. This is definitely a good thing when done right. It brings more stability to your infrastructure and applications, which allows you to provide more reliable services.
The Risk of Overdoing It
You need to be aware that Change Management brings a risk on its own: paralyzing your work with bureaucracy. You do need to have a formal approach to make this process work, but the trick is to make it formal enough, while not being too formal. Let's stop using the "f" word for a while and think more practical.
If changes have been storming into the live environment day and night, being developed and implemented all over the place, you need to turn the situation around slowly. Think of it as an oil tanker; it will not turn in a couple of seconds no matter how hard you spin the steering wheel. Same here, if you make your process too rigid and move too quickly, people will circumvent it. Or they will follow it, but lose a lot of their efficiency and gladly blame on you, the innovator. To make it worse, they will do it both within the IT and in front of the business.
Divide and Conquer
Start by tightening control over a group of changes. Changes invisible to the business are a good pick. Your CEO will still get his new report by tomorrow, your Sales Manager too. However, the DBAs cannot just add another index to the database now, because they think it will work better. They actually have to get an approval first. Believe me, you need to divide and conquer. It is hard enough to deal with resistance within IT. You do not need to struggle with the business side at the same time. Continue to tend to your business users while you clean your own backyard. Just be sure the business uses the Service Desk to engage IT; this way you will be able to focus your actions better.
Leave Room for Exceptions
After you have picked your battle, the IT front, you need to agree to some further concessions. There will be times when changes will need to be implemented quickly, without filling out papers. Make it clear when it is allowed and make sure that the paperwork gets filled in afterwards. This way your team learns, that there is a way to address issues quickly, but documentation process is still the same. No escaping from it.
Keep It Simple
Lastly, make sure that you do not ask too much in terms of change documentation. For teams not used to documenting anything, filling in 10 pages will be an overkill. Make it really simple at the start. Something is better than nothing. Make it no more than one page form, with a few questions to be answered. Good picks are:
- What is being changed and in which system?
- What is the expected benefit?
- How was it tested?
- Who will implement it?
- When will it be implemented?
0 comments:
Post a Comment