Configuration Management Services

Change Management

Change management is an important process, because it can deliver vast benefits (by improving the system and thereby satisfying "customer needs"), but also enormous problems (by ruining the system and/or mixing up the change administration).

Furthermore, at least for the Information Technology domain, more funds and work are put into system maintenance (which involves change management) than to the initial creation of a system. Typical investment by organizations during initial implementation of large ERP systems is 15-20% of overall budget.

The process and its deliverables

For the description of the change management process, the meta-modeling technique is used. Figure 1 depicts the process-data diagram, which is explained in this section.

Figure 1: Process-data model for the change management process


There are six main activities, which jointly form the change management process. They are: Identify potential change, Analyze change request, Evaluate change, Plan change, Implement change and Review and close change. These activities are executed by four different roles, which are discussed in Table 1. The activities (or their sub-activities, if applicable) themselves are described in Table 2.

Table 1: Role descriptions for the change management process




The customer is the role that requests a change due to problems encountered or new functionality requirements; this can be a person or an organizational entity and can be in- or external to the company that is asked to implement the change.

Project manager

The project manager is the owner of the project that the CHANGE REQUEST concerns. In some cases there is a distinct change manager, who in that case takes on this role.

Change committee

The change committee decides whether a CHANGE REQUEST will be implemented or not. Sometimes this task is performed by the project manager as well.

Change builder

The change builder is the person who plans and implements the change; it could be argued that the planning component is (partially) taken on by the project manager.

Table 2: Activity descriptions for the change management process




Identify potential change

Require new functionality

A customer desires new functionality and formulates a REQUIREMENT.


Encounter problem

A customer encounters a problem (e.g. a bug) in the system and this leads to a PROBLEM REPORT.


Request change

A customer proposes a change through creation of a CHANGE REQUEST.

Analyze change request

Determine technical feasibility

The project manager determines the technical feasibility of the proposed CHANGE REQUEST, leading to a CHANGE TECHNICAL FEASIBILITY.


Determine costs and benefits

The project manager determines the costs and benefits of the proposed CHANGE REQUEST, resulting in CHANGE COSTS AND BENEFITS. This and the above sub-activity can be done in any order and they are independent of each other, hence the modelling as unordered activities.

Evaluate change


Based on the CHANGE REQUEST, its CHANGE TECHNICAL FEASIBILITY and CHANGE COSTS AND BENEFITS, the change committee makes the go/no-go decision. This is modelled as a separate activity because it is an important process step and has another role performing it. It is modelled as a sub-activity (without any activity containing it) as recommended by Remko Helms (personal communication).

Plan change

Analyze change impact

The extent of the change (i.e. what other items the change effects) is determined in a CHANGE IMPACT ANALYSIS. It could be argued that this activity leads to another go/no-go decision, or that it even forms a part of the Analyze change request activity. It is modelled here as a planning task for the change builder because of its relationship with the activity Propagate change.


Create planning

A CHANGE PLANNING is created for the implementation of the change. Some process descriptions (e.g. Mäkäräinen, 2000) illustrate that is also possible to ‘save’ changes and process them later in a batch. This activity could be viewed as a good point to do this.

Implement change

Execute change

The change is ‘programmed’; this activity has a strong relationship with Propagate change, because sometimes the change has to be adapted to other parts of the system (or even other systems) as well.


Propagate change

The changes resulting from Execute change have to be propagated to other system parts that are influenced by it. Because this and the above sub-activity are highly dependent on each other, they have been modelled as concurrent activities.


Test change

The change builder tests whether what (s)he has built actually works and satisfies the CHANGE REQUEST. As depicted in the diagram, this can result in an iterative process together with the above two sub-activities.


Update documentation

The DOCUMENTATION is updated to reflect the applied changes.


Release change

A new SYSTEM RELEASE, which reflects the applied change, is made public.

Review and close change

Verify change

The implementation of the change in the new SYSTEM RELEASE is verified for the last time, now by the project manager. Maybe this has to happen before the release, but due to conflicting literature sources and diagram complexity considerations it was chosen to model it this way and include this issue.


Close change

This change cycle is completed, i.e. the CHANGE LOG ENTRY is wrapped up.


Besides activities, the process-data diagram (Figure 1) also shows the deliverables of each activity, i.e. the data. These deliverables or concepts are described in Table 3; in this context, the most important concepts are: CHANGE REQUEST and CHANGE LOG ENTRY.
A few concepts are defined by the author (i.e. lack a reference), because either no (good) definitions could be found, or they are the obvious result of an activity. These concepts are marked with an asterisk (‘*’). Properties of concepts have been left out of the model, because most of them are trivial and the diagram could otherwise quickly become too complex. Furthermore, some concepts (e.g. CHANGE REQUEST, SYSTEM RELEASE) lend themselves for the versioning approach as proposed by Weerd, but this has also been left out due to diagram complexity constraints.

Table 3: Concept descriptions for the change management process




A required functionality of a component (or item; NASA, 2005).


Document describing a problem that cannot be solved by a level 1 help desk employee; contains items like date, contact info of person reporting the problem, what is causing the problem, location and description of the problem, action taken and disposition, but this is not depicted in the diagram (Dennis, et al., 2002).


Document that describes the requested change and why it is important; can originate from PROBLEM REPORTS, system enhancements, other projects, changes in underlying systems and senior management, here summarized as REQUIREMENTS (Dennis, et al., 2002). Important attribute: ‘go/no-go decision’, i.e. is the change going to be executed or not?


Distinct entry in the collection of all changes (e.g. for a project); consists of a CHANGE REQUEST, CHANGE TECHNICAL FEASIBILITY, CHANGE COSTS AND BENEFITS, CHANGE IMPACT ANALYSIS, CHANGE PLANNING, TEST REPORT and CHANGE VERIFICATION. Not all these have to be included if the process is terminated earlier (i.e. if the change is not implemented).


Concept that indicates whether or not “reliable hardware and software, technical resources capable of meeting the needs of a proposed system [i.e. change request] can be acquired or developed by an organization in the required time” (Vogl, 2004).


The expected effort required to implement and the advantages (e.g. cost savings, increased revenue) gained by implementing the change. Also named economic feasibility (Vogl, 2004).


An assessment of the extent of the change (Rajlich, 1999).


“A scheme, method or design for the attainment of some objective or to achieve something [i.e. the change]” (Georgetown University, n.d.), in this case the change.


“A non-specific term used to denote any product, including systems, subsystems, assemblies, subassemblies, units, sets, accessories, computer programs, computer software or parts” (Rigby, 2003); has (overlapping) subtypes ADDED ITEM and CHANGED ITEM.


Self-explanatory: a newly created ITEM; subtype of ITEM.


Self-explanatory: an ITEM that already existed, but has been altered; subtype of ITEM.


“A document that describes the conduct and results of the testing carried out for a system or component [affected by the change]” (IEEE, 1991).


According to the Pennsylvania State University Libraries (2004) definition, DOCUMENTATION is “[p]rinted material which accompanies other materials (usually non-book), and which explains, gives instructions for use, or otherwise functions as a guide to the major materials.” In this context, it can also be digital materials or even training, as long as it relates to (pieces of) the system.


“[M]erchandise issued for sale or public showing” (Princeton University, 2003). Consists of one or more ITEMS and the accompanying DOCUMENTATION.


A determination of whether or not the result of the change implementation fulfils the requirements established earlier (Rigby, 2003).

Besides just ‘changes’, one can also distinguish deviations and waivers. A deviation is an authorization (or a request for it) to depart from a requirement of an item, prior to the creation of it. A waiver is essentially the same, but than during or after creation of the item. These two approaches can be viewed as minimalistic change management (i.e. no real solution to the problem at hand).


Process-data model for the change management process. Created by Marijn Plomp; free to use.This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License.