Question 1: Do standards aid in the development of a CM plan?

All participants responded that yes, standards definitely help. Various reasons were cited for the help they provide a person in writing a CM plan. An overwhelming response was that standards can be used as guidelines to provide the document author with ideas as to what to consider putting in the CM plan. One person interviewed responded that his/her organization had no standards available when they wrote their plan, and suffered greatly as a result. It took them much longer to write the plan and it wasn't nearly as complete as it should have been. The additional time spent writing the plan was because they didn't know what should be in it, and they didn't know what they really needed to do to perform CM effectively. This interviewee was writing a CM plan for the first time and stressed heavily how much standards would have helped. Several people interviewed stated that standards are essential for a person who is new to the CM area and writing a plan for the first time. In addition, standards serve as an excellent checklist for the experienced person.

While all participants felt standards played a key role in CM plan development, one person did state that some standards are too bureaucratic and that these standards are better avoided than used.

Question 2: Should CM procedures be part of the CM plan or be separate?

This is perhaps the most debated issue these days. Many authors have addressed this topic in their books and have stated their opinions. Our purpose in asking this question was to determine how industry viewed this issue.

There was overwhelming agreement that the procedures should be separate from the plan. A plan describes what you will do and a procedure describes how it will be done. All agreed that the plan should reference the procedures, and one valuable insight was that the plan should also state what audience each procedure is intended for (e.g., CM personnel, developers, QA), but no one felt that the procedures should be placed directly in the plan.

There were many reasons cited by the respondents for separating the two. Primary among these reasons were the following:

• Separating procedures from the plan allows people to read only what applies to them; this becomes increasingly important as the size of the project and plan get larger. It becomes very difficult to get a programmer to look through a one-hundred page plan to find the part that relates to checking code in and out, but a programmer will be quite likely to look at a three page procedure.
• Maintainability is much easier with the procedures separated; the procedures change frequently, and if they are in the plan, the plan will have to be updated frequently. However, if the procedures are not part of the plan, the plan can be left at a higher level, and thus become more static.
• The plan is more of a philosophy document used as a check to verify that you are doing things right, whereas the procedures provide specific steps (working instructions) on how to do something.
• The plan is for a broad audience but individual procedures are written for very specific audiences.

Question 3: Is the CM plan updated throughout the project life cycle?

Eight of the ten respondents stated that they update their plans throughout the project life cycle. The other two stated that developing the plan was a one-time event. In one of these cases, the plan was created to document the CM process, and once documented the procedures were created and used to do the actual work. Since the process was at a high level, there was never any real reason to change it. What changed in this case were the procedures. In the other case, the plan was written and never updated; however, if the project had to change the way it performed CM, a deviation form would be created documenting how the project was deviating from the written plan.

Those that did state that they update their plans noted that updates were not done frequently. They also stressed that updates should be kept to a minimum and should only be done when there are major structural or process changes. The general feeling was that it was good to update the plan, if updates were not carried to an extreme. All stated that their plans did not require many updates because they broke their procedures out from their plans.

Two respondents stated that they update their plans primarily because the contract requires this to be done. They did not gain much benefit by the plan updates because the day-to-day work was done according to procedures; however the updates satisfied the contract, and also gave some visible insight to higher levels of management as to how CM functions.

Question 4: Was the CM plan used after it was developed? If so, by whom and how?

Most respondents stated that the CM plan was used primarily in the initial stages to establish the process by which CM would be done, and to document this process for approval. The plan provided the author with a structure to work against to ensure that he/she did not forget to handle any of the key CM functions. After this, it basically took up shelf space, as the procedures became heavily used. No organization used the plan in their day-to-day operations, however all stated that if the procedures were part of the plan this would change. Half of the respondents did state that they did use their plans occasionally to review their approaches and basic philosophies, and to determine what impact a large change in one CM process might have on other CM processes.

Regarding use of the plan, we found that on occasion CM plans are used by organizations other than CM. QA uses the plan to perform audits on CM and also to coordinate with CM on how QA becomes involved in code reviews and other similar functions. The plan is also used by management and software team leaders to determine staffing, and establish agreement on how CM will be performed on the project. Finally, the contracting agency uses the plan in their audits of the project.

Question 5: Is there a need for a CM plan at the company/division level as well as at the project level?

Most respondents stated that they felt there was a need for either a generic plan or standard at the company level, or if the company was large, at the division level. In addition, most respondents leaned towards having a standard rather than a plan. They felt that since much of the information is project specific, a standard would be better. All respondents stated that if there was a plan at the company level it would have to be written so that it could be easily tailored for the individual projects.

Those that felt it was important to have a company-wide standard or plan stated that the reasons for this were that the plan/standard would dictate to the projects the company's policy for CM and the way the company wanted CM handled, and would give the projects a foundation upon which to build their individual plans. This foundation would include processes and methodologies endorsed by the company.

One respondent did not feel there would be a great deal of value in having a plan at the company level unless all of the projects in the company worked with the same product line. However, if they shared the same product line, this respondent felt that perhaps even many of the procedures could be created at the company level.

Question 6: Are there significant differences between a CM plan written for a development project and a CM plan written for a maintenance project?

The overwhelming response to this question was "no." The respondents felt that the CM plan for both was basically the same, and that the differences between the two were minor and could easily be handled with one format or template for a CM plan. The respondents noted that the majority of the differences would be in the CM procedures, but that procedures would probably be different even for two development projects. One respondent noted that good CM methodology is the same regardless of what it is applied to, and that the plan should document this methodology. The largest differences noted by another respondent were that development must address prototyping and maintenance must address emergency fixes. While both of these events can occur both in development and maintenance, they commonly occur in one or the other more frequently and thus, must be much better thought through.

Of the ten people interviewed, four have written plans for both development and maintenance projects.

Question 7: Are there significant differences between a CM plan written for hardware versus software?

Again, the majority of the respondents answered "no," stating that it was the procedures that would most likely be different. One respondent noted that hardware control is becoming much more like software control, and the largest difference in this respondent's opinion was in the type of person you hire to actually control the hardware or software, not in the documentation of this control. This respondent also noted that at the finer level of details there is quite a bit of difference, but that these details should be located in procedures, not in the process methodology. Another respondent stated that a plan can be easily tailored to address both hardware and software just by separating the various sections for both.

Of the ten people interviewed, three have written plans for both hardware and software.

Question 8: Are there significant differences between a CM plan written for a large project versus a small project?

Most of the respondents answered this question by stating that there are some differences, but that the same plan template or example can be used for each with minor alterations. The largest differences noted were that as a project gets larger, it generally becomes more complex and requires more coordination. With the increased complexity and need for coordination, the plan must also grow to address these issues.

One respondent pointed out that in a small project there is often no need for a separate CM organization, and that the CM plan is often folded into the project management plan. Also noted by several of the respondents was that small projects don't necessarily need to address all of the components that would need to be addressed in a larger project. For example, a small project may not need much, if anything, in terms of status accounting reports, an identification tracking scheme, or retention policies. Most respondents stated that a small project would likely concentrate on items such as a simple change/version control process, simple configuration identification criteria, and configuration release policies. As with the prior two questions, most respondents felt that the largest differences between a small and large project would be in the level of detail that the procedures would contain, and the overall number of procedures that would need to be developed to perform CM on the project. Any changes to the plan itself could easily occur by removing unnecessary sections of the plan template for a small project.

Of the ten people interviewed, two have written plans for both large and medium sized projects, one has written plans for both small and medium sized projects, and one has written plans for both small and large sized projects.

Question 9: Is there any real value in writing a CM plan? If so, what is this value?

All of the respondents stated that there was value in writing the CM plan, however, the amount of value felt by each was different. A few respondents felt that the plan was very valuable throughout the entire life cycle. Others felt that it was only valuable at the beginning of the project, and once produced, had basically served its purpose.

The most common reasons stated regarding the value of the plan were the following:

• The plan documents the CM process and as such acts as the tool used to gain project and management support for the process.
• The plan forces you to define and describe the process.
• The plan causes you to think about what you will do and how you will do it.
• The plan serves as a contract vehicle for the project.

Question 10: What makes a CM plan hard to write?

Most of the respondents stated that the CM plan itself is not hard to write; the difficult part is determining how to perform CM and what processes you will implement. Once you know what you are going to do, documenting it is easy. However, several respondents did note some reasons for the difficulty in writing the plan.

One reason cited was that it is difficult to get input and cooperation from software engineering and software development while developing the plan; and if you don't have their input and agreement, you can't write an acceptable plan or develop an acceptable process. Another reason cited was that the timeline to write the plan is generally short, and you need to have your process well-defined before you can begin writing the plan. It is often the case that the process is not well-defined before management is wanting you to document it. A third reason cited was that it is difficult to write the plan so that it can be effectively implemented, and also be easily used by all parties. A final comment was that the plan itself was not difficult to write, but enforcing it and getting people trained in the procedures were the most critical barriers to making the plan effective.

It is clear that lack of a defined CM process makes it impossible to write the CM plan. But, given a well-defined process, it is not difficult to write the plan. When writing the plan it is necessary to keep the audience in mind and ensure that the plan is written in such a manner that it will be accepted, enforceable, and easy to use.