While SCM engineers could labor to create an SCM plan from scratch, they could also create a comprehensive plan by following an existing guideline, such as IEEE standard 828-1998. An SCM plan created according to this widely accepted standard would detail a project’s or an organization’s approach for

1. identifying configuration items and establishing software baselines, 
2. reviewing, approving, and controlling changes to configuration items, 
3. tracking and reporting changes to configuration items, and 
4. auditing and reviewing configuration items. 

Once carefully prepared, SCM engineers expected that the SCM plan would outline the process and reference the detailed procedures needed to manage changes to the software system under development.

While the act of preparing an SCM plan may sound like a step in the now obsolete waterfall model of software development, it need not be an exercise that runs counter to today’s iterative and incremental software development approaches. Modern software development approaches, such as agile methodologies, recognize that it is not possible to plan every detail in the process of building the software system. Instead, these approaches emphasize responding to changes that are an unavoidable part of the software development lifecycle.

Since iterative software development focuses on responding to changes, SCM engineers can create a practical SCM plan by helping an organization define the approach it will follow for addressing changes that occur throughout the software development lifecycle. Unlike other problems that arise during the software development lifecycle, certain configuration management issues are almost predictable on software development projects. Whether planned or not, activities like identifying and versioning configuration items, creating baselines, and managing proposed changes to baselines take place during the software development lifecycle. A practical SCM plan should address these and other matters.

SCM engineers must realize that more important than writing the plan is asking the questions needed to prepare the plan. By raising these questions to the development team, the SCM engineer will force the team to think about how they will develop and manage changes to the software system. Ideally, the SCM engineer should pose these questions at the start of the software development project. In the same way that a business analyst probes subject matter experts to gather information about the domain, the SCM engineer should question key members of the development team to gain insight into the team’s approach to software development. Even if the development team is newly formed, the members bring experience and knowledge of successful development approaches from other projects.

The engineer tasked with preparing the SCM plan should begin by identifying principal members of the development team, such as the project manager, architect, lead analyst, lead developer, and lead tester. The SCM engineer should then schedule an interview with each key member, rather than interview these members in a group. The objective of each interview is to obtain the team member’s perspective of the project’s software development process. At the start of each interview, the SCM engineer should ask the team member to describe the approach that the team follows to obtain the requirements for the software system and to translate these requirements into working code that is either deployed in a production environment or prepared for commercial distribution. Hopefully, the SCM engineer can use the team member’s response to this open ended question to develop a conversation focused on the team member’s areas of expertise in the software development lifecycle. During the conversation, the SCM engineer should probe further based on the team member’s role on the project. For example, the SCM engineer could ask the project manager to describe when software baselines need to be created and when they need to be delivered. Similarly, the SCM engineer could ask the lead tester how bugs are reported, or ask the lead developer how proposed code changes are reviewed and approved. Interviews with key members of the development team should also include questions about activities described in the SCM plan, like how configuration items are identified, named, and placed under version control.

The information gathered during the interviews should reveal the scope of the project team’s software development and software configuration management processes. Whether the project team uses a formal process or an agile methodology, the interview results will show the degree to which members of the project team thought about and addressed common configuration management issues that are likely to surface throughout the software development lifecycle. For example, the interviews may show the extent to which the project team employed branching strategies to support concurrent development. Additionally, the interviews may shed light on the usefulness of the project team’s change control process.

Using the information gleaned from the interviews, the SCM engineer should be able to draft an SCM plan using an existing template or standard. When writing the draft plan, the SCM engineer may need to fill in details not covered by team members during the interviews. In addition, the SCM engineer may need to resolve conflicting approaches advocated by different team members.

Once the draft plan is complete, the SCM engineer should present it to the leadership of the software development team, i.e., the team members interviewed to gather information to prepare the plan. When meeting with the leadership, the SCM engineer should describe the purpose and content of each section of the plan. The SCM engineer should explain how the content of the plan came about by tying plan content to interview results. The SCM engineer should use the meeting as a forum to resolve concerns raised by the participants.

When revised and approved, the SCM plan can serve as a roadmap for the configuration management activities of the development team. It should be introduced to the entire development team by project management and should be placed in a location where it can be accessed electronically, at any time, by all members of the development team.