8.4 Change Request

Change requests derive from event registrations. An event registration always gives rise to a change request for each of the configuration items to be changedeven though the same change will be implemented two different places. An event registration must not be closed until all change requests have been approved. It may look as illustrated in Figure 8-9.

Figure 8-9. Change Requests Derived from an Event Registration

Event registration and change requests are frequently combined, so that information belonging to the change request is registered directly in the event registration. Although this may seem more efficient, it really isn't, because it makes it more difficult to track changes. It's a good idea to always make both an event registration and a change request, even if they have a one-to-one relationship, because it's then no problem to trace when a one-to-many relationship occurs. The former are more frequent at the beginning of a project. The further in the life cycle, the more complex the items and, hence, the more frequent the one-to-many relationships. In informal contexts, change requests may also arise spontaneously. In any case, all corrections must be documented.

Life Cycle and Responsibility

A change must go through a defined life cycle, as indicated above. Typical phases may be creation, implementation, and approval.

Content

A change request should contain these data elements:

• The change: identification, identification of the underlying event, configuration item concerned , and priority

• Phase information for the change: phase, date and time, name of the person responsible, description

Identification

Every change request must have a unique identification; this will typically be a number in a specified series.

Event

Every change request must have a unique reference to the event registration that caused it.

Configuration Item

Every change request must have a unique reference to the configuration item it concerns. A change request should never have more than one item attached to it, unless it can be ensured that this does not make registration and reporting of progress unnecessarily difficult.

A change request always gives rise to the identification of a new configuration item in which the change must be implementedtypically a new version of the item to be changed. This reference may be to the new as well as the old item and must be as precise as possiblepreferably with the unique identification of the configuration item(s).

Priority

Every change request should be given a defined priority, such as a number on a scale from 1 to 5, with 1 as the highest priority, or indications like "Immediate," "Urgent," and "Convenience." It's important to specify the indications of priority used and to define their meanings clearly.

Phase Indication

See the description in the previous section.

Date and Time

See the description in the previous section.

Created

In this phase, the rest of the data elements may have the meanings shown in Table 8-4.

Table 8-4. Data Elements for a Change Request in the Creation Phase

Data Element	Meaning
Name of the responsible person	The name of the person responsible for the whole change request; this will typically be the project manager or a group manager.
Description	A description, as exhaustive as possible, of the required change. This may also contain an estimate of the resources required to carry out the change, such as in calendar time or man-hours

Implemented

In this phase, the rest of the data elements may have the meaning shown in Table 8-5.

Table 8-5. Data Elements for a Change Request in the Implementation Phase

Data Element	Meaning
Name of the responsible person	The name of the person responsible for implementation of the change in the configuration item concerned
Description	A description, as exhaustive as possible, of the change that has been made. This should contain a precise indication, given in the same unit of measurement as the estimate, of the resources required to implement the change.

Approved

In this phase, the change has been approved and is accordingly closed. The person responsible for this phase will be the person who has approved the correct implementation of the change. This may be the person responsible for test or quality assurance. This description may be important, especially if the change is not approved and the change request is sent back into the life cycle.

New Events

It may happen that while carrying out a change, one comes across new events. One may find mistakes in the configuration item being worked on or in other related items. These events must be registered just like all other events, with the type "internal" or the like.

Examples

This section contains two examples of change registration forms, one for a configuration management system with a low degree of formalism and one for a high degree of formalism. In systems of the lowest formality , e-mail may be used to communicate change requests based on events.

Low Degree of Formalism

Figure 8-10 shows an Excel workbook used to register and follow change requests derived from events. All project members may access the book, and change entries may be sorted by any of the columns to produce various overviews of the information. The file c1.doc may contain a further explanation of the change.

Figure 8-10. Excel Workbook Used for Change Request Registrations

High Degree of Formalism

Figure 8-11 shows a change request form. A form should be used to follow each accepted change during its life cycle and can be used for signatures for documentation of progress. Since the life cycle of changes may be quite complicated, a procedure describing the life cycle and how to register information is useful.

Figure 8-11. Change Request Life Cycle Registration FormHigh Degree of Formalism

As in the case of event registration, a change request today will seldom be on paper. Figure 8-11 gives an idea of what information to collect and communicate for a change to be implemented and may also serve as inspiration for the layout of a full change request report.