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