I have a view of SCM implementation that focus around how the developers actually utilize the SCM system.
(SCM, Software CM)

First, the SCM-process, if available, is the organizations view of how SCM should be implemented and executed in any given development project. It should supply templates, checklists and define roles that are needed to fulfil the directives given by the process.
Then, I like to define a somewhat new term, called the SCM-method, which describes how SCM is to be executed for the specific project in accordance to the SCM-process.

I define three separate phases of the SCM-process, Planning, Establishment and Operations. To fulfill these phases, I have defined eight work packages of related activities that need to be processed. The activities comprise amongst others tool selection, installation and SCM-method development.

The SCM-method, of course, comprise the CM-plan definitions, such as naming conventions, delivery type identitfication etc. All standard mumbo jumbo... :-)
But, besides the CM-plan I argue that each project also need a complementary delivery instruction, which specifies excatly how the activities is supposed to be executed by the developers doing the actual work.

My sentense is that it is always the developers that execute the core SCM activities, which, if needed, on a larger scale can be summoned in status accounting or reviewed in an audit, but most of all handled on project top level by the SCM responsible within the project.

So, when using a specific SCM-tool for handling technical development data, the delivery instruction should define how the tool is to be used, i.e. which development role will do what actions, and when to do it.

The benefit of an overall common SCM-process is that tools and methods can be reused and most of all, the first two phases of planning and establishment can be shortened, so that the project members quickly can get up to speed and start the development work, aided by the SCM-tools.

Furthermore, I state that in a small project you might allow to skip the definitions stated by the CM-plan, for as long as the users can supply the needed SCM data while using the tool - with an optimal method - it is always possible to collect and summarize all interesting data on a management level, when needed.

My conclusion:
* It is not always nescessary to DOCUMENT an SCM-method. The important thing is to DEFINE the SCM-method.
* SCM effects are not achived by documenting activities with rigorosity, it is by utilizing the right tool in the right way, to make it serve as a timesaving aid both for developers and for managers.

* I suggest implementation of an SCM-process that can serve as a guideline for all new development projects, aiding in the choice between the rigth SCM-tool and the right SCM-method using this tool.
* In all development projects an SCM-method need to be defined. With common process definitions on type of deliveries etc. you sometimes might not need to specifically document a CM-plan or a delivery instruction. But, when the complexity of the project so requires, the process supply the templates and a checklist on how to realize these documents in the project, serving as a platform for all developers and managers in the project.

If you would like to discuss possibilities in detail, feel free to contact me by email:

Best regards,

/Thomas Karlkvist

... here the sun shines...