Configuration Management VS Change Management - Who's in Control

[article]
Summary:
Discussion has gone around a number of times on the issue. There's even been a poll on the issue. Is configuration management part of change management or vice versa? Everyone has an opinion and there does not seem to be a consensus. What's the problem? Well, here's how I see it.

On the one hand, configuration management has a wide range of definitions.  On the other hand, change management covers a number of organizational functions.

Change Management
Consider change management, to start. I consider change management to be primarily a product management function. On the development side of things (i.e. ignoring the marketing functions), product management (PM) deals with the following:

  • Identifying what constitutes a product family and its products
  • Identifying what goes into each release of a product
  • Prioritizing in the case of fixed budget and delivery dates
  • Signing off on what goes into a product release

From this perspective, it is the product management team that has to manage changes to the product. The development team, including project management, has to ensure that the changes are done within the priorities and constraints dictated by product management and orchestrated by project management. Product management defines the workload, while project management deals with the workload.

Product management is responsible for the requirements. Project management may negotiate to ensure that the requirements are reasonable, but product management represents the customer and/or market that manage changes to the product definition. Close to release time, product management should also be involved in determining which problems are going to be fixed and which are not, because fixing problems has an inherent risk of destablizing a product and, at some point, the risk is unacceptable.  From my perspective, managing change has to be done first and foremost at the product level.

Within the development team, there is another layer of change management, often referred to as change control. It's a crucial function, and ensures that change is controlled, and that there is traceability of changes to the requirements that vary from checkout policies and change packaging to change dependencies. This aspect of change management is definitely part of Configuration Management (CM), at least in my books.

There is also an in-between layer of CM that, I would argue, rightly belongs under project management. This deals with which changes are going to go into which builds. It also deals with when the most risky changes should be applied to the product, how much change should be absorbed before full verification and/or regression testing, etc. This is part of project management. It deals with how we organize the workflow most effectively to complete the workload. Is this part of CM? It certainly must be supported by the configuration management tools and process.

The three main areas of change management are:

  • Product management:  what changes go into each release of the product
  • Project management:  controlling the flow of changes to maximize chances of successful delivery of each release, on time and within budget
  • Change control:  ensuring that each change follows packaging, traceability and checkout guidelines.

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01