to be defined, so they should have a say in it. It’s much better to argue about the details during the review process instead of at the eleventh hour before a build. This will also help a great deal later on when you are trying to get project members to actually follow the process. They already had their chance to change things, so anyone who resists later on has to face up to the fact that they already gave their approval.
How do You Write an SCMP?
Don’t worry, you don’t have to sit down with a blank piece of paper and just start writing one. You can always start out with a plan you inherited from another project or start with a template. If your organization does not have an SCMP template, there are standards you can find online and you can even ask other CM’ers right here on CM Crossroads to share their templates with you. There have already been threads posted on this topic. One great example that I found in a thread was a reference to the whitepaper “Configuration Management (CM) Plans: The Beginning to Your CM Solution" written by Nadine M. Bounds and Susan A. Dart. This paper can be found on the Software Engineering Institute at Carnegie Mellon University site at www.sei.cmu.edu. It’s not an actual template, but a great guide to what you should include and how it should be written.
If you were part of a large organization, it would be a good idea to have a work group draft up a template that meets everyone’s needs. The act of creating a template also helps you to address many CM issues, and it’s scope reaches across a higher level than just a single project.
Once you have a template, you just go through it and see how it’s contents apply to your project’s situation. It’s a template, after all, and you can add and delete things as you see fit. One thing to avoid is getting into too much detail about how you do things. For example, you don’t have to describe the exact process of how a user checks a file out of the source code library. You should have a separate procedure that describes how a user uses the source code library and the SCM tool, but this document should only be referenced in the SCMP, not spelled out step by step. The SCMP should cover how changes to the source code library are made, where the library is located, and what the file structure of the library looks like, but not every detail on how it is used. I personally create separate procedures on topics such as using the SCM tool, building the software, and exactly how change control is implemented. These documents are all referenced by the SCMP so that a user knows where to look to get the detail, but it keeps the SCMP much shorter and cleaner. This also allows the called out procedures to be tweaked without having to consult the Change Control Board for every little change, and it allows new users to tackle the detail one document at a time instead of trying to get through one whole document.
What Kind of Things Do I Include?
Reviewing the templates will give you much more information on exactly what you should include, but I’ve covered a few of the highlights below.
To start off, you should have a section that describes what makes up the SCM group and what their responsibilities are. Usually this includes things like managing the SCM library and the