You have to have a plan, Man


SCM tools used. Then you should have a section that describes the SCM activities which could include how things are identified in terms of versioning schemes, how change control items are identified, how project baselines are created, and so on.  You should have a section that describes the item libraries, like how many there are, where they are located, what kind of retention policies you have, and what the disaster and recovery plans are (or where they can be found).

You should also have a whole section on change control.  How do things change, and how are the changes controlled?  Who is on the Change Control Board and what are their responsibilities?  What kind of tools will be used for change control?  Again, you don’t want to detail out exactly how users perform all of these items, but you do want to explain the methodology behind how these items will be accomplished.

Another important item you include in your SCMP is what objects you are going to control.  You want to have a list of those items, but once again, you don’t want to get into too much detail depending on the item.  For example, you do want to control all source code, but you don’t want to have to list every single source code file in the project.  Instead, you can simply identify them by their file extension.  For example, if you are programming in C++, all files with a ‘.cpp’ extension would have to be controlled.  You want to make sure you include all file extension types in your list, because there are files that you don’t want to control, such as intermediate files that are created by the build.  You should also decide if you are going to control the executables created by the build.  Some prefer this option, but others argue that they are re-creatable so they don’t belong under source control.  Either way, you spell out the way you plan on doing it in your SCMP. You should also list all your critical documents such as your requirements, specifications and project management plan.  Since there usually are not a large number of these documents, it’s a good idea to identify each of them individually.

You also should spell out the status accounting of CM Activities.  I’m not talking about the little old man with the adding machine accounting, but what kind of reports will be run, how often and who will be the recipient?  How will release media be stored and distributed?  What is the release process?  What items will actually be released?

Finally you should have a section on auditing.  What kinds of audits will be performed and how often?  To whom will results be reported.  One item that should be audited is the SCMP itself.  After it has been written, does it contain everything that is required by the organization?  Auditing is most common on projects that are following some kind of discipline such as Software Engineering Institute’s Capability Maturity Model, but they can be handy for any organization that wants to make sure everyone is following the rules, or that the rules are at least clearly defined.

In conclusion, the best way for you to really learn what an SCMP is all about and how it can help you in your Configuration Management duties is to actually write one.  The first attempt might not solve all your configuration management issues, but the experience will get you on the right track to having a better configuration management policy.  A good configuration management policy will then help you to get better results in less

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.