CM: THE NEXT GENERATION of SCM For Small Business

The introduction of SCM into a project involves:

1. Identifying a CM/ALM process to be followed
2. Acquistion
   of tools to support CM/ALM
3. Customization of the tools to support the process
4. Training of personnel on the CM/ALM tools and process
5. Training CM managers and administrators to support the process
6. Sufficient quality management to ensure the process is being followed and is beneficial

Are these steps different today than they used to be?   Not really.   The steps are the same, but the cost and effort should be dramatically lower.   If not, as a Small or Medium sized Business (SMB), you need to look around more.

1.  Identifying a CM/ALM process

I remember back in the 1970s and 1980s spending a substantial amount of time
trying to derive the best CM processes.   Back then, SCCS was the predominant model and that was nothing more than a version control tool with some branching capabilities.   Combine that with Make files and we had a "CM system" - or so some thought.   Fortunately I worked for larger telecom companies back then and had time
to figure out that change packages were a necessity, that release stream-based
development was the natural way for a telecom project to progress, and that
version control (i.e. delta compression to a single file) was only a minor part, at best, of CM.   One of the most successful proprietary CM tools of it's day, Mitel's SMS (Software Management System), was up and running for years before delta compression was even considered - and when it was introduced, there was no change to the user interface, and no additional training - just some disk space savings - significant though that was at the time.

We spent a lot of time understanding what was necessary and what was not.   We introduced problem tracking, project/activity management, document management, and tied them all together in with the rest of the CM system.   After carefully considering how change packaging had to work and how baseline management could be automated from changes, we gradually built up our CM tools.   They were completed to the level of true 2nd generation tools at a cost of well under a $1 million.   And since they were in-house tools, we had the flexibility to change them to work the way we wanted.

Unfortunately, we were not, primarily, in the CM business.   Although the benefits easily justified the costs, the tools eventually reached a level where the business case for continued changes was less and less clear.   After all, the tool did what we
wanted for the most part.   So how could we justify a team for second and third level feature requests?

The good thing was that we were able to build a tool that matched the process elements that we had decided were crucial.   From automating baselines, doing change-based configuration management, and ensuring proper traceability between changes and features/problems, to ensuring we had adequate reports showing us project progress, product quality (in terms of both problems found and test case results), we had a process that helped us to continually improve and tools that could be modified to support such improvements.

We didn't have starting points such as Sigma 6, CMM/CMMI, ISO 9001, or later frameworks.   Instead, we had experience - from previous projects and from earlier iterations on our current projects.   We knew our processes and tools would have to survive decades of use and would have to scale up.

The same is not true today.   We have some excellent starting points for CM process.   These come from quality standards/frameworks, from tool vendors, from
experienced CM consultants and from places such as CM Crossroads.   Identifying the requirements of a CM process is no longer a large effort, but rather an engineering task