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. labelling files, separate branches for promotion, explicit designer branching, etc.), as opposed to automated. 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. 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. I'll use Configuraton Management to manage source code, test cases and documentation.
Managing change is an ongoing decision-making process, closely tied to risk management. Configuration Management is an ongoing tracking process - it provides the traceability and the persistent access to information based on a specified context.
Can we agree?