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.
Configuration Management
How do we define configuration management? Unfortunately this is not as easy - there isn't a hard and fast definition - or rather, there are a number of them.
Is CM part of Project Management? This largely depends on your definition of CM. For example, whether or not any delta compression is used on source files is not really a project management issue. I've been on large projects where the delta compression was slipped in one day to conserve disk space and no bearing on managing the project.
Similarly, project management may identify when a baseline should be created, but should not deal with the CM function of creating it. I think this should always be an automated function based solely on change selection. Others have differing views.
I consider CM as dealing with managing the artifacts. However, it is also a perfectly acceptable definition of CM to include management of the artifacts and the processes that produce them. In that interpretation, I would say that CM is part of project management.
This tends to be the case when a lot of CM is manual (e.g., labeling files, separate branches for promotion, explicit designer branching, etc.), as opposed to automated systems. For these sorts of things, CM strategy documents need to be developed, hence a shifting of CM functionality into the realm of project management.
However, shifting CM into project management does not also put it under the umbrella of change management.
There is still another view, the CM tool view. I would argue that a good CM tool must support the development side of product management, project management, change management and configuration management. It must cover the whole spectrum.
So now we have 3 views of CM:
- CM is artifact management
- CM is management of artifacts and the processes that produce them
- CM is the big picture encompassing product management, project management, change management and, perhaps, customer management, depending on what your CM tool can manage.
The Definitive Answer
So, here's the final analysis: you're not allowed to disagree, unless you want to. The CM tool should cover the whole spectrum, but that doesn't make the whole spectrum CM. Rather, it's just that the CM tool is best positioned to cover the other areas.
Configuration management and change management stand side by side. Though not independent, one cannot be considered a subset of the other. I'll use configuration management to manage requirements and configuration management to manage source code, test cases, and documentation.
Managing change is an ongoing decision-making process that is closely tied to risk management. Configuration management is an ongoing tracking process that provides the traceability and persistent access to information based on a specified context.
Can we agree?
