Deliverable planning and control

For many people Configuration Management is little more than controlling the versioned storage of work products, sometimes extended with Change Control which is little more than controlling change requests and problem reports. But both boil down to something like an sophisticated database with a sophisticated tool, sometimes not even sophisticated.

But the real added value of Configuration Management is that it helps manage and control the project. Let's have a look of a project in general first. In short every project is an enterprise, a journey, to establish a particular result of a particular quality, within the limits of particular resource constraints (typically money, time, people, technology, methodology, etcetera).

Every project starts with planning. Planning the result means expressing the results in items that will be delivered - if the project is executed according to the plan. Those items need to be identified (Configuration Identification), controlled (Configuration Control) and must be of a certain quality level expressed by a status (Configuration Status Accounting). So the first order planning of - the result of - a project already involves configuration management.
Secondly, these resulting items don't fall out of the sky; they need to be developed. So every item will require at least one task in the planning that produces the item. Some tasks may even product multiple items, that's OK. But every task needs input. So there we have a second order of configuration items.
Thirdly, these second order items need to be produced also, or they are inputs to the project from an external source. These can be requirement definitions, architectural definitions or even complete subsystem implementations from another project or a previous project.

Anyway, project planning strongly involves configuration planning, which is a responsibility of configuration management. In other words, configuration management is part of project management, at least during planning.

After the planning has been built up, which involves a lot of other things to be planned as well, the project is executed according to the plan. The tasks are being executed and the (planned) items are being produced as the result of the tasks. Some items may be produced iteratively, thus producing multiple versions of it. Anyway, these items (i.e. the versions) are stored in the CM system and status is assigned to indicate the progress of the item (how far is it "ready"? which is a quality attribute) and the maturity (how good is it? which also is a quality attribute). But controlling the versions and their status - and even the status of integrated items, which is a different thing than the status of the individual parts. This is all Configuration Management, which contributes to the Project Monitoring and Control of the project.

All I am saying is that the deliverable planning and tracking processes are both part of Configuration Management and of Project Management. That's why we should not consider CM in terms of the tools, databases, licensing issues, disk or network performance issues, branching issues, access control, etc. Those issues are not configuration management, but they are IT systems management issues. Configuration management is a project management discipline that is concerned with managing the physical work products of the project.