Configuration Management VS Change Management - Who's in Control

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

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.