Behaviorally Speaking: CM Planning or Planning for CM

Do you want to make mistakes or get it right?
A good CM Plan helps you avoid mistakes and increases your productivity by laying the groundwork for how you complete all of your configuration management tasks. My CM plans specify proper branching strategies, standards for baselining code (e.g. tagging, labeling), release notes, and more. Procedures such as auditing configuration items should obviously be specified in detail. If we make a mistake that could be avoided in the future then you may want to add a control to prevent this mistake from occuring in the CM plan as well. CM Plans can and should be living documents. They also should be full lifecycle documents.

CM Policy in the CM Plan
High level CM plans often state the policy of the configuration management process. Yes, there should also be a separate CM policy document; I have often put this in the organizational CM plan as well.

Here are three points that I always include:

1. All configuration items in a production release (or QA for that matter) must be readily identifiable. That means that if it is running in production, you can easily tell me what version it is for every configuration Item (e.g. runtime executables, libraries, config files, docs and anything else). This includes hardware chips and circuit boards as well.
2. You must be able to retrieve the source code used to create any CI (without having to resort to heroic efforts). If I check the version id of my hello.exe - I can tell you exactly what baseline of source code I used to build and deploy the code.
3. You can create a sandbox and make a small change without any chance of the code regressing due to the wrong version of a header file or some other configuration item.

The standards for CM Planning
I have the distinct privilege of serving on the IEEE 828 CM planning standards board. Our working group meetings are an awesome discussion of how to best describe and promote industry best practices for configuration management. Our discussions involve implementing configuration management best practices on a full-lifecycle basis and most importantly in a way that is harmonized with the other industry standards (e.g. ISO, EIA) and frameworks (e.g. Cobit 4.1, ITIL v3). I have written other articles that provided an outline of the 828 standard (although IEEE rules require that I limit my quotes to 10% of the standard). You should certainly contact me if you are interested in getting involved with these efforts.

Conclusion
Your CM plan should reflect your own goals and requirements. Some organizations have contractual requirements for what they include in a CM plan and others just need to document procedures so that they do not make mistakes. CM planning is also just good communication and will help your team improve their productivity and, of course, produce better quality code!