Change management (engineering)

Last updated

The change request management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. Its main goals are to support the processing and traceability of changes to an interconnected set of factors. [1]

Contents

Introduction

There is considerable overlap and confusion between change request management, change control and configuration management. The definition below does not yet integrate these areas.

Change request management has been embraced for its ability to deliver benefits by improving the affected system and thereby satisfying "customer needs," but has also been criticized for its potential to confuse and needlessly complicate change administration. In some cases, notably in the Information Technology domain, more funds and work are put into system maintenance (and change request management) than into the initial creation of a system. [2] Typical investment by organizations during initial implementation of large ERP systems is 15 to 20 percent of overall budget.

In the same vein, Hinley [3] describes two of Lehman's laws of software evolution:

Change request management is also of great importance in the field of manufacturing, which is confronted with many changes due to increasing and worldwide competition, technological advances and demanding customers. [4] Because many systems tend to change and evolve as they are used, the problems of these industries are experienced to some degree in many others.

Notes: In the process below, it is arguable that the change committee should be responsible not only for accept/reject decisions, but also prioritization, which influences how change requests are batched for processing.

The process and its deliverables

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

Metamodel change management.png

Activities

There are six main activities, which jointly form the change request 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 request management process
RoleDescription
CustomerThe 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 managerThe 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 committeeThe change committee decides whether a CHANGE REQUEST will be implemented or not. Sometimes this task is performed by the project manager as well.
Change builderThe 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 request management process
ActivitySub-activityDescription
Identify potential changeRequire new functionality [5] A customer desires new functionality and formulates a REQUIREMENT.
Encounter problem [5] A customer encounters a problem (e.g. a bug) in the system and this leads to a PROBLEM REPORT.
Request changeA customer proposes a change through creation of a CHANGE REQUEST.
Analyze change requestDetermine technical feasibilityThe project manager determines the technical feasibility of the proposed CHANGE REQUEST, leading to a CHANGE TECHNICAL FEASIBILITY.
Determine costs and benefitsThe 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 modeling as unordered activities.
Evaluate changeBased on the CHANGE REQUEST, its CHANGE TECHNICAL FEASIBILITY and CHANGE COSTS AND BENEFITS, the change committee makes the go/no-go decision. This is modeled as a separate activity because it is an important process step and has another role performing it. It is modeled as a sub-activity (without any activity containing it) as recommended by Remko Helms (personal communication).
Plan changeAnalyze change impactThe 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 modeled here as a planning task for the change builder because of its relationship with the activity Propagate change.
Create planningA 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 changeExecute changeThe 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 changeThe 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 modeled as concurrent activities.
Test changeThe 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 documentationThe DOCUMENTATION is updated to reflect the applied changes.
Release changeA new SYSTEM RELEASE, which reflects the applied change, is made public.
Review and close changeVerify changeThe 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 changeThis change cycle is completed, i.e. the CHANGE LOG ENTRY is wrapped up.

Deliverables

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, [6] but this has also been left out due to diagram complexity constraints.

Table 3: Concept descriptions for the change request management process
ConceptDescription
REQUIREMENT A required functionality of a component (or item; NASA, 2005).
PROBLEM REPORTDocument 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).
CHANGE REQUEST 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?
CHANGE LOG ENTRY*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).
CHANGE TECHNICAL FEASIBILITY 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).
CHANGE COSTS AND BENEFITS 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).
CHANGE IMPACT ANALYSIS An assessment of the extent of the change (Rajlich, 1999).
CHANGE PLANNING “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.
ITEM “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.
ADDED ITEM*Self-explanatory: a newly created ITEM; subtype of ITEM.
CHANGED ITEM*Self-explanatory: an ITEM that already existed, but has been altered; subtype of ITEM.
TEST REPORT “A document that describes the conduct and results of the testing carried out for a system or component [affected by the change]” (IEEE, 1991).
DOCUMENTATION 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.
SYSTEM RELEASE“[M]erchandise issued for sale or public showing” (Princeton University, 2003). Consists of one or more ITEMS and the accompanying DOCUMENTATION.
CHANGE VERIFICATIONA determination of whether or not the result of the change implementation fulfills the requirements established earlier (Rigby, 2003).

Besides just ‘changes’, one can also distinguish deviations and waivers. [7] 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 request management (i.e. no real solution to the problem at hand).

Examples

A good example of the change request management process in action can be found in software development. Often users report bugs or desire new functionality from their software programs, which leads to a change request. The product software company then looks into the technical and economical feasibility of implementing this change and consequently it decides whether the change will actually be realized. If that indeed is the case, the change has to be planned, for example through the usage of function points. The actual execution of the change leads to the creation and/or alteration of software code and when this change is propagated it probably causes other code fragments to change as well. After the initial test results seem satisfactory, the documentation can be brought up to date and be released, together with the software. Finally, the project manager verifies the change and closes this entry in the change log.

Figure 2: Example change request for the car industry Example change request.png
Figure 2: Example change request for the car industry

Another typical area for change request management in the way it is treated here, is the manufacturing domain. Take for instance the design and production of a car. If for example the vehicle's air bags are found to automatically fill with air after driving long distances, this will without a doubt lead to customer complaints (or hopefully problem reports during the testing phase). In turn, these produce a change request (see Figure 2 on the right), which will probably justify a change. Nevertheless, a – most likely simplistic – cost and benefit analysis has to be done, after which the change request can be approved. Following an analysis of the impact on the car design and production schedules, the planning for the implementation of the change can be created. According to this planning, the change can actually be realized, after which the new version of the car is hopefully thoroughly tested before it is released to the public.

In process plants

Since complex processes can be very sensitive to even small changes, proper management of change to industrial process plants is recognized as critical to safety. Undocumented, not properly risk assessed changes are a recipe for disaster. An eminent example of this is the Flixborough explosion, where improvised changes involving the bypassing of a stage in a reactor train was at the origin of the accident. The change had not been properly thought out, documented and risk-assessed, so that the event of breach of containment had not been identified. [8] In the US, OSHA has regulations that govern how changes are to be made and documented. The main requirement is that a thorough review of a proposed change be performed by a multi-disciplinary team to ensure that as many possible viewpoints are used to minimize the chances of missing a hazard. In this context, change request management is known as Management of Change, or MOC. It is just one of many components of Process Safety Management, section 1910.119(l).1.

See also

Notes and references

  1. Crnkovic & Persson-Dahlqvist (2003).
  2. Dennis, Wixom & Tegarden (2002).
  3. Hinley (1996).
  4. Huang & Mak (1999).
  5. 1 2 Actually, there is no need for both a requirement for new functionality and a problem detected to occur in order to get a change request. Usually only one of the two will. Modeling them as unordered activities approximately approaches this meaning. An alternative would be to create two separate "starting points" (i.e. initial states), both pointing to Request change.
  6. Weerd (2006).
  7. Scott & Nisse (2001).
  8. Mannan (2012).

Referenced literature and further reading


Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

A web service (WS) is either:

Software configuration management (SCM), a.k.a. software change and configuration management (SCCM), is the software engineering practice of tracking and controlling changes to a software system; part of the larger cross-disciplinary field of configuration management (CM). SCM includes version control and the establishment of baselines.

Model Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model Driven Architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Product data management (PDM) is the name of a business function within product lifecycle management (PLM) that denotes the management and publication of product data. In software engineering, this is known as version control. The goals of product data management include ensuring all stakeholders share a common understanding, that confusion during the execution of the processes is minimized, and that the highest standards of quality controls are maintained. PDM should not be confused with product information management (PIM).

<span class="mw-page-title-main">Data modeling</span> Creating a model of the data in a system

Data modeling in software engineering is the process of creating a data model for an information system by applying certain formal techniques. It may be applied as part of broader Model-driven engineering (MDE) concept.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

<span class="mw-page-title-main">Activity diagram</span> Graphical representation of a workflow

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration, and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes, as well as the data flows intersecting with the related activities. "Object nodes hold data that is input to and output from executable nodes, and moves across object flow edges. Control nodes specify sequencing of executable nodes via control flow edges." In other words, although activity diagrams primarily show the overall control flow, they can also include elements showing the data flow between activities through one or more data stores.

<span class="mw-page-title-main">Change request</span>

A change request, sometimes called change control request (CCR), is a document containing a call for an adjustment of a system; it is of great importance in the change management process.

Synchronization Models, also known as Configuration Management Models, describe methods to enable revision control through allowing simultaneous, concurrent changes to individual files.

<span class="mw-page-title-main">Phased adoption</span> Implementation strategy

Phased adoption or phased implementation is a strategy of implementing an innovation in an organization in a phased way, so that different parts of the organization are implemented in different subsequent time slots. Phased implementation is a method of System Changeover from an existing system to a new one that takes place in stages. Other concepts that are used are: phased conversion, phased approach, phased strategy, phased introduction and staged conversion. Other methods of system changeover include direct changeover and parallel running.

ITIL security management describes the structured fitting of security into an organization. ITIL security management is based on the ISO 27001 standard. "ISO/IEC 27001:2005 covers all types of organizations. ISO/IEC 27001:2005 specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented Information Security Management System within the context of the organization's overall business risks. It specifies requirements for the implementation of security controls customized to the needs of individual organizations or parts thereof. ISO/IEC 27001:2005 is designed to ensure the selection of adequate and proportionate security controls that protect information assets and give confidence to interested parties."

Customer Configuration Updating (CCU) is a software development method for structuring the process of providing customers with new versions of products and updates production. This method is developed by researchers of the Utrecht University.

<span class="mw-page-title-main">Structured analysis</span>

In software engineering, structured analysis (SA) and structured design (SD) are methods for analyzing business requirements and developing specifications for converting practices into computer programs, hardware configurations, and related manual procedures.

Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable to and useful for some predefined class of problems.

<span class="mw-page-title-main">Process-data diagram</span>

A process-data diagram (PDD), also known as process-deliverable diagram is a diagram that describes processes and data that act as output of these processes. On the left side the meta-process model can be viewed and on the right side the meta-data model can be viewed.

<span class="mw-page-title-main">Control-flow diagram</span> Business process modeling tool

A control-flow diagram (CFD) is a diagram to describe the control flow of a business process, process or review.

Robustness testing is any quality assurance methodology focused on testing the robustness of software. Robustness testing has also been used to describe the process of verifying the robustness of test cases in a test process. ANSI and IEEE have defined robustness as the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions.

Dimensions CM is a software change and configuration management product developed by OpenText Corporation. It includes revision control, change, build and release management capabilities.