CM Planning or Planning for CM

Configuration management planning is one of the classic functions that separate organizations with good IT controls from the shops that are mired in making the same mistakes over and over again. I have worked in teams that had excellent CM plans and teams that were hopelessly resistant to CM planning. As much as I advocate and promote CM best practices (including CM plans), I have also always maintained that too much planning is just as bad as no planning at all. The best approach involves a pragmatic balance between the light process approach of agile planning and the more classic CM planning. So what exactly do you put into a CM plan and how do we create plans that help get the work done more effectively? Read on if you want to raise the bar in your skills at effective CM planning.

Which CM Plan did you mean?
I have seen CM plans that covered a variety of topics from branching and labeling patterns (adopted as an organizational standard) to official documents that met contractual requirements to conform to well-accepted industry standards such as the IEEE 828. CM Plans can give you the rules of the road for using a tool or specify the target dates for releasing the product (often called a release plan). Deciding what your CM plans should include must always be a direct response to your goals and requirements.

The CM Planning hierarchy
I have worked in very large organizations where I had companywide responsibility for implementing CM best practices including source code and release management processes. In these environments, I usually find that I can specify a high level CM plan that covers the rules of the road that apply to every team in the organization. Then I will optionally work with the individual teams to create more detailed CM plans that are specific to each individual group. I advocate that each team  set and enforce standards, but I show flexibility in terms of the details of each plan. I have found that the plans are actually followed when the team takes ownership.

The Culture of CM Planning
My column, going back ten years now, has always focused on addressing some of the behavioral issues involved with implementing software and systems development processes. I have learned that the culture and relationship issues are just as important as the technical issues if you really want to implement lasting change and best practices that actually work in the real world. That means that I always consider the culture of the group that I am working with to be a critical factor in the design of any process that I try to implement. For example, CM planning in a mainframe cobol environment is very different than an agile-centric Java team. Similarly, CM planning at a defense contractor or engineering firm is often considerably different than a NYC financial services firm (e.g. hedge fund). You would think that losing a million dollars would put a company on the playing field with flying planes the wrong way, but that is not always the case. Government agencies have their own cultural issues when examining their CM plans, which I have found equally fascinating to observe and analyze. Make sure that you consider the cultural issues of your team and implement CM plans that will work in the environment where they are being implemented.
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!