Don't be discouraged, though. There is a disciplined approach you can use to minimize the negative impact on your IT infrastructure.
Who does what and when?
You need to determine the roles of specific people in your Windows change management process. An individual may be responsible for several roles, or several individuals may fulfill a single role. For example, the change management manager can be the entire change management team in a small Microsoft environment.
The change management manager manages the process for all change management requests and reviews each request for completeness. The person in that role verifies that the stated objectives of the request can be met and are consistent with the company's best practices. He or she has the discretion to deny requests that are not consistent with company policy or best practices.
The change management requestor originates the request by submitting a written or online Request For Change (RFC) to the change management manager.
The change management implementer makes the necessary changes as requested in the RFC and notifies affected parties if corresponding changes need to be made. For example, changes made to Active Directory or Exchange are implemented into production by the change implementer.
The change management team is formed to manage the objectives of the specific request and is composed of members representing the technical, functional and management communities. This team will meet as needed to review, approve or reject all proposed changes and schedule the appropriate changes to your Windows environment
The change management procedure
- A request must be submitted to the change management manager.
- If the initial request is approved by the change management manager and is not an emergency change, an appropriate change management team is formed.
- An impact analysis is performed by a member of the change management team to determine what applications are affected by the change if an outage is required and the approximate costs and risks associated with the request. A back-out plan is also developed and included in the impact analysis to ensure that unsuccessful changes or undesirable results do not have an adverse impact on business processes.
- The change management team will meet as needed to review proposed changes. The change management manager is the coordinator of the change management team.
- If a request is denied, the requestor is notified in writing.
- Requests that are approved are categorized by priority (critical or normal), a change management implementer is assigned, an implementation date is determined and responsibility for end user communications is assigned.
- Emergency changes and IT changes: In the event of an emergency requirement for a change, the change management manager must approve a change prior to implementation and document the reason for the change, implementation notes and appropriate testing. The change management manager will review all approved emergency changes and IT changes periodically with the IT Manager.
- The change management team will develop test scripts as necessary and assign test responsibilities so users can validate the changes in the production environment. User acceptance information (for example -- name, date, summarized results, as applicable) is documented in a database.
Once completed and tested, the documentation and history of the project are retained. All user approvals that were captured by email will be also be saved. The change management manager will maintain copies of approval emails in his or her email files to facilitate validation of the contents of emails.
Harris Kern is the author of 44 IT and self-help books. He is recognized as the foremost authority on providing practical guidance for solving IT management issues. Harris is the founder behind Harris Kern's Enterprise Computing Institute and the best-selling series of books published by Prentice Hall. The series includes titles such as IT Services, IT Organization and CIO Wisdom. Harris can be reached at firstname.lastname@example.org.
This was first published in April 2007