Appendix B

Evolution of the Practice Standard on Project Configuration Management

This practice standard was developed from a driving need to explain in detail the interactions of the controlling processes within the PMBOK® Guide–Third Edition. During the development of the PMBOK® Guide 2000, several gaps were identified in the controlling processes throughout the document. The scope of closing those gaps as well as the explanation of how configuration management (CM) interfaced with project management was just too voluminous. This resulted in the projected changes being outside the scope of the PMBOK® Guide.

The next evolution was to determine the best mechanism for clarifying the issues found in the PMBOK® Guide. The Standards Member Advisory Group (SMAG) debated and concluded that a practice standard would be the best solution for explaining how CM plays into the project management realm.

Practitioners of the project management discipline battle every day with changes to their projects. Controlling these changes is the process of Configuration Control. Configuration management (CM) is the parent discipline to Configuration Control. The Practice Standard on Project Configuration Management provides guidance to the project manager and project team for establishing (or ensuring the establishment of) a sound CM process for the life of a project.

In March of 2002 the Practice Standard on Project Configuration Management Project was chartered. This mechanism began the process of finding volunteers and to write the first release of the standard. A Project Leadership Team (PLT) was formed with Elden F. Jones II, MSPM, PMP serving as project manager. The project was organized with a deputy project manager and managers for content, quality, configuration management, and editing. The PLT prepared operating documentation including work breakdown structure (WBS), project management plan (PMP), configuration management plan, and schedule. Initially, the PLT and volunteers conducted discussions on why another standard was being developed. Throughout the year 2003, the project documentation was refined and the process of seeking and assigning volunteers continued. The PLT developed a straw man for the standard, which the SMAG approved.

In early 2004, the content team was formed. Initially, the content team spent several weeks discussing the charter and scope of the standard. Considerable discussion centered on the differences between prescriptive and proscriptive language. The content team also discussed the value which the project configuration management standard should deliver to the reader. The team found that other PMI documentation and standards treated CM as a tool, rather than addressing “project CM.” The content team agreed to present CM as a transcendent supporting process on a project. This helped develop a standard that filled the gap between the high-level CM standards such as ISO 10007 and detailed standards such as EIA 649.

The content team was organized into groups for each major portion of the straw man outline. Each group was responsible for developing content based on the straw man outline and the group discussions. Most of the volunteers had little experience or training with CM. Accordingly, volunteers were assigned where their other experiences would prove beneficial. The volunteers with CM experience were assigned as leads for particular sections of the practice standard.

The guiding principles for the Practice Standard on Project Configuration Management:

• Provides guidelines that are relevant to project managers and project teams on the requirements and responsibilities of a sound CM system for their project;
• Is consistent with the PMBOK® Guide–Third Edition;
• Does not mirror the PMBOK® Guide–Third Edition, but provides additional background and detailed information on the practice of configuration management and is more prescriptive than the PMBOK® Guide–Third Edition;
• Aligns itself with other PMI, American, and International standards, as well as common practices within the field. Future editions will continue to refresh the material and keep the practice standard aligned with future practices implemented by the leaders within the field;
• Provides the what, when, and why CM should be implemented on projects; and
• Contains templates and samples of templates and structures used for a successful CM process. Detailed information shall be provided on the use of each of the samples and templates.