The basics in most CM Plans
The IEEE 828 Standard includes sections on the purpose and goals of the plan, scope, tasks to be completed, key terms, and references. It also includes major sections on:

• SCM Management (e.g. responsibilities, authority for completing tasks)
• SCM Activities (e.g. all tasks to be completed)
• SCM Schedules (e.g. Release Calendar)
• SCM Resources (e.g. tools, physical and people resources required)
• SCM Plan maintenance (e.g. the plan is kept current)

I would strongly recommend that you get yourself the official copy of the IEEE 828 CM Plan, from the IEEE, and drop me a link if you have questions about how to use the plan in your own organization.

Does your team know how to baseline their code?
The most basic requirement of any CM process is to create accurate and secure baselines for any release that might be promoted to production. It's my experience that many teams do not know how to create baselines of their code in an accurate and foolproof way. An amazing number of development teams actually create baselines that can be accidently deleted - leaving the organization without any reliable way to track the exact versions of the code that are running in production. Your CM plan should specify a completely reliable way to baseline your code, including a reliable way to lock down baselines so that they cannot be inadvertently deleted.

Branching (and merging) strategies
I have seen many CM plans that included complex branching strategies including conventions on branch (and Tag/Label) naming conventions. I have also seen approved CM "patterns" such as private branches. The use of integration branches (often to support Continuous Integration - CI Servers) is also usually specified in CM Plans. Integration with Defect Tracking systems and Change Requests (CRs) is also usually specified in a CM Plan.  Basically, a well written CM plan helps new (and existing) members of your development team get up to speed more quickly and complete their tasks more effectively.

Don't forget the process
Many standards working groups (including the 828 CM Planning group) are focusing on defining standards that are more process based. Your CM plan should specify exactly how your team will perform all of their CM related processes including application packaging and release management. Standards typically specify "what" should be done, but your own plans should also dive deep into exactly "how" your plans will be carried out - including your own procedures for auditing compliance and providing visibility to senior management. For example, if some groups refuse to attend Change Control meetings and that results in production outages then CCB meeting attendance should be part of your IT Governance dashboard. Senior Management would also benefit from knowing how many Releases actually make their way into production. (I have worked in organizations where senior managers had no idea of how many releases were being generated and supported by their staffs to respond to customer demands.)

ITIL and Cobit
Both ITIL v3 (from the itSMF) and Cobit 4.1 (from ISACA) have a tremendous amount of wisdom that could provide valuable input to your own CM Plans. You should review both of these excellent frameworks and incorporate their well considered wisdom into your own best practices. Using Standards and Frameworks effectively will help you learn from the experiences of other smart and accomplished technology professionals.

Harmonization and tailoring
Harmonizing means that you look for commonality between standards and frameworks. For example, every CM Standard and Framework talks about baselining as a best practiced and required competency described in any CM Plan. But you may find that combining the Control Practices in Cobit 4.1 for Change and Configuration Management "harmonizes" well with the use of CMDBs described in ITIL. Your CM Plan should "harmonize" the best practices that you need regardless of the source. Tailoring means that you trim down any aspect of the plan that is not absolutely necessary. It is critical for you to trim down your use of standards and frameworks to the absolute minimum, including those included in your CM Plan. Any extra "ceremony" will undermine the credibility of your plans and processes.

Documenting to become MORE Agile
I have worked in many Agile environments where fixing the release management processes allowed the team to work more effectively in an iterative (and Agile) way. This meant that the organization could build and release in an hour, where previously it took them a week or two (and then they still made mistakes). Defining effective Agile processes helps your team get the work done faster and with a much higher level of quality. For example your CM Plan should include instructions on how to handle a patch release and, of course, emergency releases when necessary.

Improving the process
Mistakes happen. Mistakes are not bad (unless they happen more than once). I try to use mistakes as a positive learning experience. You need to always consider updating your CM Plans to avoid making the same mistake twice. CM Plans should be improved as needed. Continuous Process Improvement should be part of your corporate culture and a core team competency!

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and was recently elected to the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment