Having been integrated into the SCM shopping and buying experience for hundreds of different companies I thought I could share some helpful tips on what to look for when embarking on this type of task. Here are my top five tips.

I. Review the SCM fundamentals

If you have never used an SCM product before, or have only used one or two programs like VSS or CVS, it maybe a good idea to brush up on software configuration management. There are a lot of books and web sites that provide information on methodology which can really bolster the SDLC process itself. I find that a lot of people have only used CVS or VSS a limited knowledge of SCM concepts beyond the basic capabilities that these tools provide.

A found a good introduction to SCM in the book Practical Software Configuration Management. After reading these book which provided a good background on SCM in general I also went on to read Software Product Management Essentials which deals with the management aspect of the SDLC. This important because the SDLC process will be tightly woven into the SCM product, and it is important to know what type of SDLC process that will be used before selecting the appropriate SCM tool. The next bit of recommended reading came in a more advanced document from IEEE. We feature this document on the Seapine web site and its called The Importance of Branching Models in SCM. This document is so popular you can now find it on dozens of web sites included other SCM vendor pages. This was an excellent document on how to make the development process much more effective.

If you do not have a very solid background in SCM and SDLC management fundamentals these resources will be a very big help and allow you to better define the scope of your SCM needs.

II. Determine the scope of your SCM needs

There are a lot of SCM tools on the market, open source and commercial. They all work somewhat the same, in that they provide versioning of files, but can have many important differences. These differences can be given attributes that are applied to need. A lot of times the more expensive tools like IBM’s ClearCase are designed for larger scale high risk environments. The less expensive and open source tools like CVS are intended for smaller groups and focus on speed and simplicity. The number of people in the organization who will use the SCM tool can be used as one of the factors to determine what type of tool you need. A group of 300 users working on a hundred million dollar projects using RUP might opt for a high end product, while a group of 3-5 users working on customized web applications using lightweight and Agile may opt for a more low end product. The former has high capability but also high overhead in cost, training and time to install and maintain the product while the later will boast quicker setup and lower overhead but less capability.
A sample list of primary attributes might be:

Number of users – How many people will use the system
Size of Database – Scale of the source code repository
LAN or WAN user access – How will performance for external users be effected
Risk/Security Management – How critical is the source code repository

A small list of initial requirements can then be used to isolate some SCM candidates whose price points and feature set match. Tools that are designed for 100’s of users should not be considered for smaller groups. Tools with database size limitations can be eliminated if they appear not to support your estimated needs. Products without external access or risk management features can also be removed from consideration for larger projects.

This initial requirements gather is fairly basic and short, but essential. In a relatively short period of time, perhaps one meeting with your team for 30 minutes, you can define the basic scope of your need. This initial need can be used to determine what type of tool you are looking for. There are all manner of large, small and any number of in-between sized tools to choose from so consider this the first step to honing in on your ideal candidates list. Like most things in life you get what you pay for, large cost often comes with greater number of features and higher end functionality. Later on we will focus on feature requirements.

III. Product Comparisons
At this stage two things should be fairly clear. How you want to implement your software development process, and what your basic level of requirements are. Using these two guidelines you’ll be able to select and evaluate different SCM products to look for more specific features you may be interested in like Email notifications, reporting, merging, diffing and more. There is an excellent article on CMCrossroads which talks about making this an organized project.

There are many other considerations that can be made. Off-site, hosting of the SCM projects are available for some commercial and open source vendors. Compliance is a big ticket item right now and some products will have features designed to provide for these requirements. New process improvement and security methods like CMMI and ITIL
There are links you can find online that will provide feature charts for comparisons of various SCM products, usually open source one’s. These can be very good references guides, but be wary of such charts that exist on SCM vendor sites as they will be written with bias towards their own product. Wikipedia.org seemed to have some good references to such sites but unfortunately some of the better links appear to be dead at this time.

Putting Part II and Part III will provide a comprehensive list of requirements for your team needs, all you need to do then is match the requirements to the best suited vendor. Feature requirements can be hard to gather and are often broken in down into weighted categories like “Must have”, “Would like to have” and “Not important”. Only the show stopper items should be listed in the “Must have” category that way any vendor evaluating your requirements can tell you right away if they will meet your needs or not. Since a lot of products have different ways of accomplishing the same things keep the “Must have” list shortened down to the bare essentials. You can then score the vendors who have all the “Must have” items to determine who has the most “Would like to have” and “Not important” items in addition to weighting in other factors like cost, customer support, company history and mindhsare (information you can find out from friends, colleagues or on the net in user forums, blogs and other public spaces about the vendor and product).

IV. Product Evaluations

After the list of SCM vendors has been narrowed down to a list of 2-5 these products should be installed and tested locally for no less then 2 weeks. Most commercial products offer on-site evaluations, although some products such as IBM’s ClearCase do require a lot of time and effort to get going so usually a company representative or local partner will come to your offices to perform the setup for the evaluation. This should not be frowned on, your time is important why waste it trying to setup and install a new program when a company rep can come out and do it for you. It is a good idea to rely on the vendor for information on installation, configuration and getting started with the product. This will serve two purposes, it will save some of your time doing those things by working with the company and it will allow you a chance to evaluate the company’s customer service.

I’ve had potential customers call and ask random technical questions just to ‘test’ out our tech support services. I have no problem with this approach and encourage others to follow this example. When you make a decision and select an SCM product you are also selecting that company, or in the case of open source products the online user community (there are also commercial organizations that offer CVS/SVN support services), that represent the tool so it is important to know about both as you will be working with both.
When doing an evaluation of a product make sure to use real data, real situations and as many people who can spare the time to test drive the system. If you are planning to implement a new SDLC process this would be a good time to trial some of the key concepts of that process to make sure everyone will be comfortable with the changes and that they will result in a benefit for the team. For example the IEEE document references earlier refers to a specific way of managing code changes for defects, for someone considering thinking of switching to their Branch by Purpose method this would be a good time to setup an eval system using that approach and test the results.

V. Buying Decisions

There are a lot of things to consider when making the final buying decision. In many cases there are two or even more products which meet the SCM requirements and other attributes like price, nice-to-have features, and quality of the organization become intangibles that factor into the buying decision. The small 3-5 user group might be satisfied with free tools with are supported by extensive online user forums, while the large 300 user group may need, may even require, a professional services contract from a commercial vendor to solve problems when they arise.

Stakeholder buy-in to the project is very important. Getting everyone to agree to using an SCM tool at all can be a huge hassle but that is an article for another day. Getting everyone to use a new SCM tool will be easier if everyone who has to use the program has had a chance to evaluate it and provide feedback. Any objections to the application can then be addressed before a purchasing decision is made which in turn will make implementation of the new product a much smoother process.

There is nothing worse then buying a new tool only to have it collect dust on the shelf because the no one knows how to use the tool, or because no one wants to use the tool for one reason or another. Developing an implementation plan prior to making a purchase decision. Make sure that your users understand that an SCM tool is designed to make software development easier and not create more work for them. In many cases this can be proven during the product evaluation, when a user can try a product without having to commit to it first they maybe more open minded and it will be easier to showcase the benefits of an SCM system. (Amazingly, to me anyways, a lot of companies are not using any SCM system at all. See why you should here!)

Once everything has been factored in including user feedback you should be ready to select an SCM tool. Implementing a new SCM tool will take time and resources, and its not something you will want to do very often. Take your time in selecting the right tool. Use all the resources at your disposal, online resources, vendor resources, friends, family, coworkers. Build your requirements list to match your needs to the right product and let the members of your group test drive the products you selected for evaluation.

Posted by pat on Thursday, January 11th, 2007 at 2:25 pm.