根据IEEE 828和CMM/CMMI，
配置管理计划常常被认为是一份文档，确实的，对于一个大项目而言，往往需要制定项目自身的配置管理计划。
但不是所有的组织都是软件外包组织，不是每个项目针对的是不同的客户。
在非软件外包的高效
软件开发组织中，推荐的配置管理计划应有三个层面。
首先是组织层面，一般，提供统一的配置管理服务，不会允许每个团队自己搭建配置管理服务器。所以对于组织级的配置管理服务要有所约定，约定的主要内容有：
如何建立项目文档目录？
如何建立产品级目录？
如何建立代码目录？
配置项如何命名？
配置库的备份和恢复如何进行？谁来进行？
什么情况下拉分支？什么情况下合并到主干？ 关于分支主干要提供多种模式，或者放开限制，让产品线或者项目组选择。
如何进行变更？ 一般应当在组织级进行定义和发布。如果放到项目层面，变更流程的制定太费功夫；当然有些大项目是有足够的预算和特殊情况需要专门定义项目级的变更。
对产品线和项目如何开展配置审计？
有什么推荐的配置管理实践？
组织级配置管理规程或者指南的更新频率在每年一次左右。
其次是产品线层面。对于特定产品线，已经存在大量的源代码和文档，那么结合实际，这个产品线在配置管理存储时有哪些约定？
比如对代码配置项和非配置项有所说明，不要假设每个团队新人都是代码配置管理达人，小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除，但发现再删除，其本身就是成本。
比如哪些依赖项值得存储？
比如哪些区域是机密，权限另外管理
比如那些代码是核心代码，如果改动需要资深人员复核。
本产品线的主干和分支策略是什么？ 守护主干？还是先锋主干？无分支？还是单分支？还是多分支？
比如约定团队统一一致的
工作环境：都把
Java装在C:/java，把eclipse装在D:/eclipse
最后是项目层面。在有了上述组织级和产品线级的配置管理约定后，项目层面的配置管理计划中最关键的是需要明确人员、基线和项目特殊配置项。其中基线的安排必须与项目本身生命周期的选择相匹配，最重要而言，必须匹配于里程碑。
在这样的三层结构下，为项目高效计，不需要单独写项目的配置管理计划，只需把项目级的配置管理约定写入项目计划即可，一般的篇幅不超过1页。