Change management (engineering)

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.

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. Typical investment by organizations during initial implementation of large ERP systems is 15 to 20 percent of overall budget. In the same vein, Hinley describes two of Lehman's laws of software evolution:
The law of continuing change: Systems that are used must change, or else automatically become less useful. The law of increasing complexity: Through changes, the structure of a system becomes ever more complex, and more resources are required to simplify it. 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. 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.

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.

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. 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.

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. 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.

Crnković I., Asklund, U. & Persson Dahlqvist, A. (2003). Implementing and Integrating Product Data Management and Software Configuration Management. London: Artech House. Dennis, A., Wixom, B. H. & Tegarden, D. (2002). System Analysis & Design: An Object Oriented Approach with UML. Hoboken, New York: John Wiley & Sons, Inc.
Georgetown University (n. d.). Data Warehouse: Glossary. Retrieved April 13, 2006 from: https://web. archive. org/web/20060423164505/http://uis. georgetown. edu/departments/eets/dw/GLOSSARY0816. html. Hinley, D. S. (1996). Software evolution management: a process oriented perspective. Information and Software Technology, 38, 723 730. Huang, G. H. & Mak, K. L. (1999). Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management, 19(1), 21 37. IEEE (1991). Standard Glossary of Software Engineering Terminology (ANSI). The Institute of Electrical and Electronics Engineers Inc. Retrieved April 13, 2006 from: http://www. ee. oulu. fi/research/ouspg/sage/glossary/#reference 6 Mäkäräinen, M. (2000). Software change management processes in the development of embedded software. PhD dissertation. Espoo: VTT Publications. Available online: http://www. vtt. fi/inf/pdf/publications/2000/P416. pdf. Mannan, Sam (2012). Lees' Loss Prevention in the Process Industries (4th ed.). Oxford: Butterworth Heinemann. NASA (2005). NASA IV&V Facility Metrics Data Program Glossary and Definitions. Retrieved March 4, 2006 from: https://web. archive. org/web/20060307232014/http://mdp. ivv. nasa. gov/mdp glossary. html. Pennsylvania State University Libraries (2004). CCL Manual: Glossary of Terms and Acronyms. Retrieved April 13, 2006 from: https://web. archive. org/web/20060615021317/http://www. libraries. psu. edu/tas/ cataloging/ccl/glossary. htm. Princeton University (2003). WordNet 2.0. Retrieved April 13, 2006 from: http://dictionary. reference. com/search?q=release. Rajlich, V. (1999). Software Change and Evolution. In Pavelka, J., Tel, G. & Bartošek, M. (Eds. ), SOFSEM'99, Lecture Notes in Computer Science 1725, 189 202. Rigby, K. (2003). Managing Standards: Glossary of Terms. Retrieved April 1, 2006 from: https://web. archive. org/web/20060412081603/http://sparc. airtime. co. uk/users/wysywig/gloss. htm. Scott, J. A. & Nisse, D. (2001). Software Configuration Management, Guide to Software Engineering Body of Knowledge, Chapter 7, IEEE Computer Society Press. Vogl, G. (2004). Management Information Systems: Glossary of Terms. Retrieved April 13, 2006 from Uganda Martyrs University website: https://web. archive. org/web/20060411160145/http://www.321site. com/greg/courses/mis1/glossary. htm. Weerd, I. van de (2006). Meta modeling Technique: Draft for the course Method Engineering 05/06. Retrieved March 1, 2006 from: https://bscw. cs. uu. nl/bscw/bscw. cgi/d1009019/Instructions for the process data diagram. pdf [restricted access].