Each day, many configuration management (CM) folks are asked by the IT organization to implement CM on a small team or in a new effort. You may be told (or decide yourself) that a full-blown CM implementation won’t be necessary due to the small size of the team. Your ability to “right size” will go a long way in how successful your CM efforts are.

When implementing CM for small teams, there are several questions you need to address: Is the minimalist approach of CM congruent with my duties to implement sound CM? Is there a difference between implementing CM on small and large teams? Can I pick and choose the concepts of CM—a cafeteria plan approach—and still stay true to the discipline of CM? The answer to these questions depends on how well CM is received at your organization and whether are there other efforts that you are working on that require a more structured approach and a more detailed CM implementation.  As a CM practitioner, you don’t want people saying, “Why do we have to do this CM practice when the other group does not?  If you don’t have answers to these questions, it could derail your CM implementations throughout an organization.

I am currently in a situation where we don’t have a CM plan for our organization. We have a process guide for our developers to use that contains our approach to CM.  It spells out the processes and procedures that developers are to follow as it pertains to CM.  This approach requires a great deal of trust between all of the software development staff.  Some may ask how CM issues are resolved without a CM plan. It depends on your organization’s maturity and ability to operate without specific instructions. First and foremost, your team should exhibit a strong culture of CM and understand its importance and necessity.

Although it is important for large teams to have a CM plan, it isn’t essential for the success of small teams. It’s more important that the team members understand the value of their own CM efforts in the team’s success. In large teams, due to the complexity of such undertakings, a CM plan is necessary because of the sheer size of larger scale implementations.  In larger undertakings, there can be more people spread out over greater distances and you lose the relationships that are usually less formal in smaller groups. Ultimately, the bulk of CM activities are performed by others, especially on small teams.  On smaller teams you usually have more functions being performed by fewer people and less separation of duties.

At my organization, our Configuration Control Board (CCB) sets priority without the aid of lead developers and business analysts and configuration management input. However, not having a full CCB has not made our work any more difficult as we are able to set priorities and work on issues that the business deems important. In small teams, only one or two individuals in the organization may set the priorities, in which case a CCB is merely a “rubber stamp” that adds no value and hinders progress.  In larger groups, a CCB might not be possible due to a variety of factors, such as geography, the levels of maturity needed to interact, and the need to “be there” for the team at all times and all situations. Your main priority in smaller implementations as a CM practitioner is to make sure that you are able to provide the basic CM needs of the group and be an enabler of success instead of a barrier to success.Your organization’s maturity will determine whether or not  the level of CM you implement is the right amount. You will know if your organization is mature enough based on past experiences and the willingness of people within the organization to follow sound CM principles, and if this level exists, you can skip some of the formalities and implement only what is needed. For example, if your team understands the importance of sound version management, consistently manages its defects and issues, baselines its code for releases, and has good release-management practices, then what good does having a four-hour, weekly CCB meeting really accomplish? How would a CM plan benefit this well-running group? Some of you may declare me an apostate to the very CM principles I say I support, but not while I am able to achieve the four activities of CM: configuration identification, configuration control, configuration status accounting, and configuration audits.

I do have a caveat to my prior statements about scaling back your CM implementation. If you are asked to implement a pilot that will be spread throughout an organization, you must use a different approach. In this case, I would have a CM plan, a formal CCB, and the bells and whistles necessary to scale the implementation to a broader audience. This will be determined by how your organization defines “small team.” How many people are in a small team? It may be six people in one company and sixty in another. You want to make sure you’re always able to scale any small effort into a larger effort.

From a CM perspective, you need strong version management—the lifeline on which all other things depend. Without a CM plan, you need to make sure that everything is kept and versioned. You must identify your configured items and ensure that defects are tracked and managed; however, you can’t use spreadsheets or email for this.  You need a dedicated tool that is robust enough to handle the amount of changes and can be accessed by your group. Excel spreadsheets, while they can be used to organize your issues, just are not scalable and can only be access by one user at a time. Not tracing issues and defects is one of the biggest mistakes small teams make, because they take for granted that being small and in close proximity insures good communication.  This leads to issues slipping through the cracks and becoming bigger problems in the future.

Someone other than the developers who wrote the code should perform the builds. If you allow developers to do the user-acceptance builds or production builds, you create a huge risk of patches and fixes that are not versioned prior to entering the system. A strong release-management ideology has to permeate the group. For example, you should limit access to production databases and code. Deployments should be a cursory action rather than potentially leading to a full-scale disaster when someone sneaks in and adds a fix of which others aren’t aware.

Implementing CM for small teams can be achieved. It will be determined by your organizations maturity, the ability of the CM practitioner to know how much CM is enough, and the willingness of the team members to adapt. It must be scalable and at the same time practical. Decisions as to how much or how little CM you implement in the smaller groups can also lead to a wider acceptance of CM from the whole organization if this is a new concept for your organization. The main takeaway should be that there is no one-size-fits-all approach that works and every implementation has the potential to be different. Our approach to CM has to be different for each project for it to be successful.