bigmacbear (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
bigmacbear) wrote2006-08-05 09:38 am
bigmacbear) wrote2006-08-05 09:38 am
Change Management
No, we aren't talking about a piggy bank or a Coinstar machine here.
This post is intended for the Information Technology (IT) folks who might be reading, so in case that's not your cup of tea it's behind the cut.
One of the more recent developments in the realm of IT is the IT Infrastructure Library (ITIL), some scheme dreamt up by the British government to minimize the costs and risks associated with computer technology. One of the main aspects of ITIL is Change Management, which basically means that every time you touch a production system, you have to plan the change in advance and have it approved by the appropriate managers. Tools exist that make this process relatively painless if a bit time-consuming.
Where this breaks down is the Change Freeze. One of the features provided by most Change Management tools is the ability to virtually shut down approval of changes whenever the executives deem this necessary. If the tool does not provide this feature, of course, a Change Freeze can always be imposed by executive fiat. (No, this is not a reference to CIO's and the like tooling around in cheap and balky Italian cars.)
Some places are really fond of Change Freezes and will impose them at the drop of a hat. It appears some audit manager (read: accountant) did a study and determined that companies are most productive during Change Freezes. The problem is, very often there are changes that really do need to be made, but can't be justified not to wait for the end of the Change Freeze.
All of this would not be a problem except when management decides to repeatedly extend and expand a Change Freeze far beyond the original dates and reasons for which it was first imposed. What happens then is predictable:
Anyone else run into this issue? And how do you schedule any work under these conditions?
Oh, by the way, just before![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
gmjambear and I left Rochester, we did a little change management of the other variety and netted over $600 (which has long since been spent).
This post is intended for the Information Technology (IT) folks who might be reading, so in case that's not your cup of tea it's behind the cut.
One of the more recent developments in the realm of IT is the IT Infrastructure Library (ITIL), some scheme dreamt up by the British government to minimize the costs and risks associated with computer technology. One of the main aspects of ITIL is Change Management, which basically means that every time you touch a production system, you have to plan the change in advance and have it approved by the appropriate managers. Tools exist that make this process relatively painless if a bit time-consuming.
Where this breaks down is the Change Freeze. One of the features provided by most Change Management tools is the ability to virtually shut down approval of changes whenever the executives deem this necessary. If the tool does not provide this feature, of course, a Change Freeze can always be imposed by executive fiat. (No, this is not a reference to CIO's and the like tooling around in cheap and balky Italian cars.)
Some places are really fond of Change Freezes and will impose them at the drop of a hat. It appears some audit manager (read: accountant) did a study and determined that companies are most productive during Change Freezes. The problem is, very often there are changes that really do need to be made, but can't be justified not to wait for the end of the Change Freeze.
All of this would not be a problem except when management decides to repeatedly extend and expand a Change Freeze far beyond the original dates and reasons for which it was first imposed. What happens then is predictable:
- A few days before the scheduled end of the Change Freeze, administrators and applications teams enter change requests, scheduled for just after the freeze, for their ongoing routine work that requires them.
- Upper management extends the Change Freeze, invalidating the change requests.
- Administrators and application teams reschedule.
- Lather, rinse, repeat.
Anyone else run into this issue? And how do you schedule any work under these conditions?
Oh, by the way, just before
gmjambear and I left Rochester, we did a little change management of the other variety and netted over $600 (which has long since been spent).
no subject
no subject
With this idea in mind, there is a full presentation and challenge of any prospective change at weekly Change Review Board. Anyone is free to contest a change, its content, necessity, adequacy of backout plans, or execution time and date. Once that change is approved OR approved with modification, it goes in. If it is declined, it may not be implemented under any circumstance.
The only "freeze" time is briefly at year end, imposed by the government body which regulates my industry.