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 of fitting existing, fairly well known methods to our process requirements, and doing a bit of customization to ensure the fit is snug.

2.  Acquisition of Tools to Support CM/ALM
There are still companies out there that decide that they need to build their own CM tools - for whatever reason.  Most of it is NIH syndrome.  There is very rarely a need today for a company to build its own CM tool.  In fact, there is a continuously smaller need to knit together tools into a complete ALM solution.   Even though there are still CM tools for which you can dish out over $10K per seat, there are quite a selection of very low cost (to free) tools that provide a significant CM benefit, and even full ALM solutions for under $1K/user.

Small businesses have to pay their employees, like everyone else.  They can't afford not to invest $1K/user to keep their competitive advantage.  The problem comes in knowing which tools to invest in to ensure that they are getting an advantage without at the same time requiring a staff-up effort to operate and support the tools.  Many fall into the trap of assuming that a freeware tool is the least expensive.  In some cases this may be the case.  But a full ALM solution is required by companies small and large to effectively manage product development.  Regardless of the cost, if the solution requires significant up front resources (including training and initial data population), significant operating administration, complex or tedious CM tasks for CM managers and/or developers, significant tool integration/glue, etc. it is not going to be suitable for small business.

Some of the key drivers of 3rd generation CM/ALM technology address these issues.  3rd generation tools generally have a small footprint, are easy to install, easy to populate from existing data, are easy to use, and have a very low administrative requirement.  As well, they have the basic set of CM/ALM features that permit an organization to achieve a high level of process maturity.  A small business should look only at 3rd generation or higher tools, or risk being swallowed up by the tools/process.  This is not to say that there aren't some nifty, low administration 2nd generation tools out there.  But they do only part of the job and you'll have to find other nifty tools to do the rest and then you have to knit them together to get your full ALM solution.  The cost in time in having to evaluate multiple tools, having to knit them together and maintain upgrades to the whole package is considerable.

3. Customization of the tools to support the process
If you're lucky, you'll find a tool that fits your process perfectly, and you'll find that your process never needs to change.  But don't count on it.  Even with a high-end, mature CM capability and process, we've found that most organizations need to change their process for one reason or another.  Some high end tools have a high degree of customization capability, but the customization capability is far from trivial.  You may need weeks of courses and still have to spend a good deal of time making the changes.  A small business can't afford this.

Instead, look for a process-centric tool that also is easy to customize.  The fact that it is process centric will likely mean that the process is easy to adapt.  But process has many components:  object state flow, workflow/rules/triggers, permissions, data schema, user interface and reports/queries.  Your process is specified in terms of roles, so your tools must allow customization in terms of roles.  The most important thing from an ease-of-use perspective is "who sees what".  You don't want your users wading through a mass of complexity, and you don't want all roles seeing the same user interface.  Ideally, you want every screen to have exactly what you want on it, without having to build your own tool.  But customization has to be easy.  You can't afford to bring in a consultant to work on your tools when you barely have enough resources to focus on your core business.

Now one option, that you may find some tool vendors somewhat keen on, is to buy the solution customized.  That is, for a small fee, or even included in the purchase price, they meet with you and identify the key customizations needed, and implement them as part of the "sales" process, so that you can evaluate the final product as part of your evaluation.  If the vendor has an easy to customize tool, this is a no-brainer for the vendor.  But if the tool is not easy to customize, you'll find that the vendor won't agree to anything without an outrageous consulting contract to go along with the tool purchase.  This is one way to easily evaluate both the vendor and the tool's customization capabilities, while at the same time getting a more exact platform to evaluate.

4. Training of personnel on the CM/ALM tools and process
If you're a small business, you want to get a tool in, spend an hour or two with your team familarizing them with the tool and then cut them loose.  You don't want to have to spend days or even weeks investing in training.  Training can easily be the highest up-front cost with some tools.

You do want to spend some time ensuring that your team understands the process.  But having understood the process, they should be able to pick up the tool in no time.  Even better still, the tool should act as a guide to help your team learn the process.  It should let each team member know what's on his or her to-do list.  It should clearly show state flows and have easy access to interactive process flow. Not many CM/ALM tools are going to do this for you, but there are some out there, and even some that won't cost you an arm and a leg.  Even better, the tools should provide on-line process help for your users and allow you to adjust the process help easily as you change the process.

The goal is to get your team up and running while learning the process.  If the tools can help teach the process that's all the better.  If not, make sure that you're aware of the costs involved.  Don't let a vendor tell you that you're having problems because you didn't do enough training.  And don't let a vendor sell you canned training.  Training has to be customized to your organization.  Look at options such as computer-aided training, or low-cost custom training packages.  This is where it helps to work with the vendor to introduce your tool customizations as part of the sales process.

5. Training CM managers and administrators to support the process
You will have to designate one or (preferably) two individuals to be the administrators of your CM/ALM solution. In most small businesses, this person will also be your CM manager.  But what if you don't have the budget to hire a CM manager.  Not to worry.  There are a number of tools out there that do not require anywhere near a full-time position for the CM manager and administration job.  There are fewer such tools that also cover the ALM function adequately, and even fewer that will cost-effectively allow the same person to adjust your processes.

Training of these personnel is typically a smaller overall expense, but a larger per person expense.  And how much can you really afford to have these key personnel absent?  Ideally, this training should be graduated - you start off with a day or two (or a week or two with some tools), and are able to keep the team running.  Another session and you can start improvements and introduce some automation.  Another session and you can eliminate the vendor loop for most issues and customizations.

As with all roles, the key for CM managers and administrators is ease-of-use.  But even more important is automation.  Automation eliminates the need for the CM manager and administrator except in extraordinary situations.  Does your CM manager have to do labelling and merging or is this automated?  How are baseline definitions put together? What do you have to do to identify what has gone into a release?  What about breaking out a new release?  Nightly builds?  Development environment support?  The more that can be automated, the smaller the role for CM managers.  And the same goes for administrators.  How is the repository backed up? How much effort do upgrades involve?  What about server operation, especially after outages?  Are there special recovery procedures that have to be learned?  The more that is automated, the less need for administration, and the less chance of human error.

The Adminstrator's job should be to understand the tools enough so that if something does go wrong, it can be quickly resolved.  It should not be a fire-fighting role or a tedious set of operations.  It should not involve having to be a database administrator.  And it should not be one of having to tune the tool and repository to get adequate performance or scalability. 

The CM manager's job should involve taking decisions and acting on them with the fewest clicks/keystrokes possible.  In a multiple product, stream-based change management environment, the CM manager would ideally signal only the out-of-the-ordinary procedures.  Nightly builds should run automatically based on changes that have been promoted in each stream.  Labelling should be automated based on the actions and context/environments of the developers and based on decisions made at the CRB.  Perhaps the CM manager may have to ask the system to freeze a baseline.  Perhaps ask the system to produce a set of tech-writer-ready release notes.  Perhaps kick-off a verification or release process.  Perhaps troubleshoot when a developer accidentally puts the right code into the wrong development stream.  But normal day-to-day operations should not require a lot of CM manager input.  As such, there should not be a lot of training required up front. A quick hands-on run-through of the daily operations and maybe some customization training.  The point is, if it's a lot more than that, then your small business is not going to be competitive because you're using a greater percentage of your resources for non-core business.

For customization, it may well be worth it to outsource customization to an expert, if one can be found at SMB prices.  But if the customization is complex, you may be binding yourself to long term contracts and costs.  So look carefully at your tools to see how much effort it is to customize.  If you're basically programming to do customization, watch out.

6. Sufficient quality management to ensure the process is being followed and is beneficial
The final mile is the most difficult.  And SMBs are pre-disposed to thinking that when they see the first working lab model, that they are into the final mile.  The final mile is shortened primarily by introducing effective process and quality procedures into the first miles.  But the final mile will still be long.  Even after all of the features have been coded and unit tested, and even integrated into a single deliverable, the verification begins.  The problem reports follow.  Then fixes.  Then a realization that some fixes will require a large rework.  More testing, new problems introduced. And the cycle continues until you know that the problem level is acceptable for beta trials and eventually for delivery.  But you'll never know if you don't have your data and processes in place.  Yes there may be a few customers who are willing to take a chance on you, but you had better not disappoint them with poor quality.  You had better be certain about your deliveries or you'll rapidly get a bad reputation that won't allow you to grow.  Instead of reference sites, you'll have horror stories.

So even as an SMB, you'll need to ensure that you're doing adequate testing.  You'll need to carefully track problems and correct them.  You'll need to be able to verify that your process is being followed correctly so that the expected benefits of the process are actually realized.  You'll need to ask your CM/ALM tools to show you what's right, what's wrong, what's improving and what's not.  And the most crucial question for a release, in the case of a small business, when do we switch from development mode to marketing and sales mode - and you may want to do that before your product is absolutely ready to ship if the sales cycle is long.

Again it comes down to having good processes and advanced tools.  Like it or not, 2nd generation CM/ALM tools are not going to cut it for small businesses.  You'll have to make up what's lacking somewhere else.   A successful entrepeneur will have the knowledge necessary to make good decisions.  It's too easy to make the wrong decision based on gut feel.  And in the case of SMBs, the wrong decision could be the last decision.  So even more than for larger companies, CM/ALM is critical.

Wrong Way
I knew a company, a spin-off smallish company, that started their development with a set of experienced team members.  They resolved to do CM "the right way".  So they went off and bought the most expensive, market leading CM tools.  The company went bankrupt and the cost of CM was no minor factor, especially when consulting costs were added in.

Out of the ashes, sprung up a new company.  They were much more discerning about their CM tools and costs.  They chose a very high end solution at a very reasonable cost from a company that did not market themselves adequately, but that they were familiar with from previous experience.  The solution worked, cut their costs dramatically, and not only did the job, but helped them to advance their processes significantly.

This is how a small business must address the CM market.  Small businesses have high-end requirements, even higher than large businesses because they have fewer resources to spare.  But there are solutions out there.  How much do you want to spend on a implementing best practices using a top-of-the-line CM/ALM tool?  Look around.  If the solution is too complex to evaluate, don't.  If it looks free but is only a small piece, beware.

Make the vendor show you that you'll save time, effort and money. Make the vendor show you that it can be adjusted to your requirements.  Make the vendor do the homework you would otherwise have to do (because they've probably already done it).  If the vendor is confident in their solution they will give you some guarantees.  Maybe it's not a 100% refund guarantee.  Maybe it's not a zero-defect guarantee.  But if they're not willing to back up their solution with anything more than words, you may want to look elsewhere.  Freeware is fine.  I use it all over the place.  But be careful what you're using it for because you may end up paying in annual salaries more than you would have paid up front for commercial ware.

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment