• To minimise IT failures caused by changes made to IT infrastructure
– This is a wonderfully clear statement that quantifies the over-riding responsibility of Change Management.
• Efficient and prompt handling of changes
– Here we are concerned with the scheduling and timing of changes. You need a central point for the registration and management of Change Requests.
• Responsibility for resolution when changes are not implemented as described
– Any alterations need to be reported back to the CAB
The question is do you get any new incidents or problems as a result of failed changes, or changes that have ‘worked’ but created new incident or problems in other IT Infrastructure components?
For example a new software item is added successfully but there is not enough memory so performance is inhibited. If you are not sure analyse your Incident and Problem Data Bases to see if any evidence exists to prove failed changes. Use this data to prove that you are missing this Change Management goal. A good idea is to ask the Service Desk staff for examples because if changes are failing they will be only too willing to help!
If any approved change cannot be implemented as specified, it should be reported back to the Change Advisory Board for tracking and resolution. Just because it cannot be implemented as requested does not mean that the change cannot go ahead, as long as the alternative does not have an impact on production services.