It's surprising how many organizations don't plan well for change. Change Control is a well known process, one that is well defined in many different frameworks (ITIL and the ISO 27000 Series and NIST for starters). Yet many organizations plan changes over coffee and a napkin (or a visio on a good day). This almost always results in figuring out problems during the change (I don't know about you, but the less 1am thinking I need to do, the better off I am!), conflicting changes, or changes that just plain don't work, and need to be backed out in a panic.
The Change Control Document that I posted above is one that I"ve used as an example for a while now. If you've got a more complete document, if there is something that you feel should be added or changed, or if I've missed anything in the process description, please use our comment form and share !
=============== |
Rob VandenBrink 577 Posts ISC Handler Nov 23rd 2012 |
Thread locked Subscribe |
Nov 23rd 2012 9 years ago |
"IT is supposed to be a support group for the larger organization, so we should be striving for planned changes. From the point of view of the larger business, we want system maintenance and upgrades to be as close to a non-event as we can possibly make it."
This is not necessarily true. The true answer is: Management doesn't want changes to interrupt business processes, if the cost is too high. If you have a server that won't boot because it's indicating keyboard error "Press F1 to continue"; you don't want a change control form, and 3 day long bureaucratic process, before an engineer is allowed to clear the error and get the service back up. If you aren't careful, excessive planning can result in cost overruns exceeding the benefits of the change -- it rules out changes that may be low-risk incremental improvements to systems, due to cost. Incremental changes, that when added up over time, might be massive improvement. Disruptions caused by change may be deemed OK if the cost is low, or the benefits of the change are high enough. A visio diagram or sketch on a napkin, might be fine in many circumstances, particularly for changes of limited scope, with full impacts that can easily be understood. When you introduce complicated changes; the full impacts may NEVER be understood and fully anticipated, even with years of planning. You have issues similar with software development.... the Engineer may require feedback from the live system while making the change, to fully chart out the best parameters, and the exact next steps. This makes it physically impossible or unjustifiably expensive to even attempt to plot out precisely in advance. Spending months planning a change, costs lots of money, in the form of many lost man hours due to excessive time spent planning or making up paperwork. Possibly massively more money, then a little extra time spent solving other problems. Therefore, it is not obvious at all, that such bureaucracy is always called for. For some cases it will be a sensible CYA measure for IT management. For other cases, such formalized change process constructions are just irrational artificial introduction of excessive complexity. |
Mysid 146 Posts |
Quote |
Nov 25th 2012 9 years ago |
Mysid - I think you're missing the point entirely. A good change process can take into account all the issues you've pointed out.
Emergency CAB process. Changes can be raised retrospectively when incidents occur so you don't have to wait three days to restart a server than has crashed. "A visio diagram or sketch on a napkin, might be fine in many circumstances, particularly for changes of limited scope, with full impacts that can easily be understood." - this is called a pre-approved change. In large organiseations, one of the big points of a CAB process is so that changes made by different teams do not effect eachother. You may have a regular, scheduled change that brings down a server every weekend, but what about the development team doing their major release in the same window? "You have issues similar with software development.... the Engineer may require feedback from the live system while making the change, to fully chart out the best parameters, and the exact next steps." - For obvious reason you typically do not test changes in a production environment, so your engineer is doing something fundamentally wrong in this case. This is a fundamental part of release management. In smaller organisations where you only have 10-15 people making changes you might not consider using a CAB, but for larger organisations with hundreds of IT staff it's absolutely necessary. |
Mysid 1 Posts |
Quote |
Nov 27th 2012 9 years ago |
Sign Up for Free or Log In to start participating in the conversation!