根據(jù)IEEE 828和CMM/CMMI，
配置管理計劃常常被認(rèn)為是一份文檔，確實的，對于一個大項目而言，往往需要制定項目自身的配置管理計劃。
但不是所有的組織都是軟件外包組織，不是每個項目針對的是不同的客戶。
在非軟件外包的高效
軟件開發(fā)組織中，推薦的配置管理計劃應(yīng)有三個層面。
首先是組織層面，一般，提供統(tǒng)一的配置管理服務(wù)，不會允許每個團隊自己搭建配置管理服務(wù)器。所以對于組織級的配置管理服務(wù)要有所約定，約定的主要內(nèi)容有：
如何建立項目文檔目錄？
如何建立產(chǎn)品級目錄？
如何建立代碼目錄？
配置項如何命名？
配置庫的備份和恢復(fù)如何進行？誰來進行？
什么情況下拉分支？什么情況下合并到主干？ 關(guān)于分支主干要提供多種模式，或者放開限制，讓產(chǎn)品線或者項目組選擇。
如何進行變更？ 一般應(yīng)當(dāng)在組織級進行定義和發(fā)布。如果放到項目層面，變更流程的制定太費功夫；當(dāng)然有些大項目是有足夠的預(yù)算和特殊情況需要專門定義項目級的變更。
對產(chǎn)品線和項目如何開展配置審計？
有什么推薦的配置管理實踐？
組織級配置管理規(guī)程或者指南的更新頻率在每年一次左右。
其次是產(chǎn)品線層面。對于特定產(chǎn)品線，已經(jīng)存在大量的源代碼和文檔，那么結(jié)合實際，這個產(chǎn)品線在配置管理存儲時有哪些約定？
比如對代碼配置項和非配置項有所說明，不要假設(shè)每個團隊新人都是代碼配置管理達人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以刪除，但發(fā)現(xiàn)再刪除，其本身就是成本。
比如哪些依賴項值得存儲？
比如哪些區(qū)域是機密，權(quán)限另外管理
比如那些代碼是核心代碼，如果改動需要資深人員復(fù)核。
本產(chǎn)品線的主干和分支策略是什么？ 守護主干？還是先鋒主干？無分支？還是單分支？還是多分支？
比如約定團隊統(tǒng)一一致的
工作環(huán)境：都把
Java裝在C:/java，把eclipse裝在D:/eclipse
最后是項目層面。在有了上述組織級和產(chǎn)品線級的配置管理約定后，項目層面的配置管理計劃中最關(guān)鍵的是需要明確人員、基線和項目特殊配置項。其中基線的安排必須與項目本身生命周期的選擇相匹配，最重要而言，必須匹配于里程碑。
在這樣的三層結(jié)構(gòu)下，為項目高效計，不需要單獨寫項目的配置管理計劃，只需把項目級的配置管理約定寫入項目計劃即可，一般的篇幅不超過1頁。