Information technology systems are often large and complex. With this size and complexity comes a growing risk of problems and faults that can affect user productivity. Users have high expectations of live systems such as file servers, web servers, databases etc. Although users generally accept that problems and faults can and do occur they expect minimum downtime in accessing live system resources. Together these two issues create a strong need for effective change management systems to support the complexity of IT systems and the demanding expectations of users. Users and IT support staff need to be able to quickly log change requests, receive a timely response that the request is being processed, be kept up-to-date with the status of the request and be informed of the outcome. All change management systems need some form of logging or reporting a request for change. These requests for change must be in writing, no matter the source, otherwise, control is lost and a change history cannot be accurately built up over time. Change must be controlled to make sure that the changes have a positive effect on all existing systems. Usually, this is done via a change request form or helpdesk call logging system.
There may be several versions of change requests to suit different users and groups within a business. End-users may have a change request form to get new software installed, managers may have change requests to organise new user accounts etc. When managing the resolution of system faults on a live system you will most likely be using an internal IT department change request form. This provides more IT-specific criteria. As you can see from the example IT department change request form both the IT Manager and CIO (Chief Information Officer) may have to sign–off on this request. The exact procedure for the change request and its approval will depend upon the policies and procedures that are in place in an organisation, the type of change required and the number of users that are impacted. A balance must be found between efficiency and risk. If too many people are involved in the approval process it can take an inefficiently long time to make small modifications. However, if too few people are made aware of the proposed change then potential problems may be overlooked. Complex and expensive changes may require a more detailed analysis than a simple change request form. Often this is done through a committee or special meeting that can include decision-makers from various sectors within an organisation and not just the IT department. The change control committee’s task is to analyse and evaluate the change request.
The results of the evaluation and impact analysis should then be added to the change management documentation. The change committee may decide to accept the change based on the assumption that they have no doubt that the change is required and can be adequately resourced. If there is some doubt or if the change is extensive, further research and testing should be conducted. A final change committee meeting can then be called to make a final recommendation for approval or an alternate solution. Decisions made by the change committee must be effectively communicated back into the change management documentation system/log.
When designing a change management system there are some important things to consider:
- All changes must be requested in writing and submitted via a hardcopy or online form for action and approval by a change control team, including helpdesk support staff and IT management.
- Is the change justified? Staff actioning change requests need to be able to identify that the requested change is necessary and make sure that any resulting modifications are beneficial to system performance.
- Change requests and resulting actions must be well documented.
- All changes must be tested before implementation and measured after implementation.
- A follow-up system needs to be in place to confirm that the action taken has solved the initial problem.
- The change management system must be easy to manage and oversee.
- Scheduling and prioritisation systems need to be in place to allow modifications to be performed effectively and in a timely fashion.
- The change management system should be able to support the allocation of resources to action the change.
- Checks should be in place to ensure that changes do not pull the organisation away from its core business or that changes in peripheral systems are not implemented at the expense of core business systems.
- Escalation processes must be in place to allow complex change requests to be actioned as quickly as possible.
- Risk analysis of system changes should be conducted. For example, they should be checked to ensure that a change in one system does not have an adverse effect on another system.
Some of the modifications resulting from change requests may be minor and only fix a small problem or the modification may focus on backend systems with little noticeable change to end-users. Other modifications may have a strong and direct impact on end-users and require training and the implementation of completely new ways of working. You need to clearly understand what will be the impact users, and what can be done to minimise the impact. Once the impact of a modification has been assessed you can consider what the user may need to do differently and include this in the documentation if new training is required to minimise this impact. No matter what the expected impact on users all changes should be documented and carefully planned. The ability to do this should be part of the change management logging system.