Configuration management planning is one of the classic functions that separate organizations with good IT controls from the shops that are mired in making the same mistakes over and over again. I have worked in teams that had excellent CM plans and teams that were hopelessly resistant to CM planning. As much as I advocate and promote CM best practices (including CM plans), I have also always maintained that too much planning is just as bad as no planning at all. The best approach involves a pragmatic balance between the light process approach of agile planning and the more classic CM planning. So what exactly do you put into a CM plan and how do we create plans that help get the work done more effectively? Read on if you want to raise the bar in your skills at effective CM planning.
Which CM Plan did you mean?
I have seen CM plans that covered a variety of topics from branching and labeling patterns (adopted as an organizational standard) to official documents that met contractual requirements to conform to well-accepted industry standards such as the IEEE 828. CM Plans can give you the rules of the road for using a tool or specify the target dates for releasing the product (often called a release plan). Deciding what your CM plans should include must always be a direct response to your goals and requirements.
The CM Planning hierarchy
I have worked in very large organizations where I had companywide responsibility for implementing CM best practices including source code and release management processes. In these environments, I usually find that I can specify a high level CM plan that covers the rules of the road that apply to every team in the organization. Then I will optionally work with the individual teams to create more detailed CM plans that are specific to each individual group. I advocate that each team set and enforce standards, but I show flexibility in terms of the details of each plan. I have found that the plans are actually followed when the team takes ownership.
The Culture of CM Planning
My column, going back ten years now, has always focused on addressing some of the behavioral issues involved with implementing software and systems development processes. I have learned that the culture and relationship issues are just as important as the technical issues if you really want to implement lasting change and best practices that actually work in the real world. That means that I always consider the culture of the group that I am working with to be a critical factor in the design of any process that I try to implement. For example, CM planning in a mainframe cobol environment is very different than an agile-centric Java team. Similarly, CM planning at a defense contractor or engineering firm is often considerably different than a NYC financial services firm (e.g. hedge fund). You would think that losing a million dollars would put a company on the playing field with flying planes the wrong way, but that is not always the case. Government agencies have their own cultural issues when examining their CM plans, which I have found equally fascinating to observe and analyze. Make sure that you consider the cultural issues of your team and implement CM plans that will work in the environment where they are being implemented.