Change Management

Logging

The first step in the change process is to record the RFCs appropriately.

An RFC can come from a variety of different sources:

• Problem Management: responsible for proposing solutions for known errors. In most cases this solution entails a change in the IT infrastructure. In this case the RFC must be registered with information about the known error in question so that the suitability of the process can be evaluated properly later.
• New Services: the development of new services usually requires changes to the IT infrastructure. In this case it is important to coordinate the whole process with capacity, availability and service level management to ensure that the changes meet expectations and do not degrade the quality of other services.
• Business Strategy: the management may decide to change strategic direction, which could, for example, affect the levels of service offered or call for the implementation of a new CRM system, etc. In general, this kind of change requires modifications to the existing hardware, software and/or procedures.
• Third-party software updates: suppliers may stop supporting old versions of software packages or introduce new versions offering significant enhancements, making it worthwhile upgrading.
• Legal requirements: a change in the legislation (such as Spain's data protection law, LOPD) may require changes in the IT infrastructure.
• Other sources: in principle any employee, customer or supplier may suggest improvements to the organisation's services, and these improvements may require infrastructure changes.

Changes do not always involve an RFC. For changes that are trivial or repeated at intervals, standard procedures may be agreed upon that do not require change management approval on a case-by-case basis.

Regardless of its origin, to log each RFC correctly at the start of the process at least the following data will be required:

• Date received.
• Unique identifier of the RFC.
• Identifier of the associated known error (where appropriate).
• Description of the proposed change:
• Reason.
• Purpose.
• CIs involved.
• Estimated resources needed for the implementation.
• Estimated time.
• Status: initially, this will be "logged".

The register must be updated with all the information generated during the process to allow detailed tracking of the RFC from its approval through to final evaluation and closure.

The information in the log must be updated throughout the whole process and must include at least:

• Updated status: "accepted", "rejected", "implemented", ...
• Date of acceptance (rejection) of the RFC.
• Preliminary change management evaluation.
• Priority and category.
• Back-out plans.
• Assigned resources.
• Implementation date.
• Implementation plan.
• Gantt chart.
• Post-implementation review.
• Final evaluation.
• Close date.