一、專案計畫書格式
根據《gb8567－88計算機軟體產品開發檔案編制指南》中專案開發計畫的要求，結合實際情況調整後的《專案計畫書》內容索引如下：
1 引言
1.1 編寫目的
1.2 背景
1.3 定義
1.4 參考資料
1.5 標準、條約和約定
2 專案概述
2.1專案目標
2.2產品目標與範圍
2.3假設與約束
2.4 專案工作範圍
2.5 應交付成果
2.5.1 需完成的軟體
2.5.2 需提交使用者的文件
2.5.3 須提交內部的文件
2.5.4 應當提供的服務
2.6 專案開發環境
2.7 專案驗收方式與依據
3 專案團隊組織
3.1 組織結構
3.2 人員分工
3.3 協作與溝通
3.3.1 內部協作
3.3.2 外部溝通
4 實施計畫
4.1 風險評估及對策
4.2 工作流程
4.3 總體進度計畫
4.4 專案監控
4.4.1 質量控制計畫
4.4.2 進度監控計畫
4.4.3 預算監控計畫
4.4.4 配置管理計畫
5 支援條件
5.1 內部支援（可選）
5.2 客戶支援（對專案而言）
5.3 外包（可選）
6 預算（可選）
6.1 人員成本
6.2 裝置成本
6.3 其它經費預算
6.4 專案合計經費預算
7 關鍵問題
8專題計畫要點
二、專案計畫書的編寫說明
1 引言
1.1 編寫目的
說明編寫這份專案計畫的目的，並指出預期的讀者。
意義：使專案成員和專案干係人了解專案開發計畫書的作用、希望達到的效果。開發計畫書的作用一般都是「專案成員以及專案干係人之間的共識與約定，專案生命週期所有活動的行動基礎，以便專案團隊根據本計畫書開展和檢查專案工作。」
例如可以這麼寫：為了保證專案團隊按時保質地完成專案目標，便於專案團隊成員更好地了解專案情況，使專案工作開展的各個過程合理有序，因此以檔案化的形式，把對於在專案生命週期內的工作任務範圍、各項工作的任務分解、專案團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、專案內外環境條件、風險對策等內容做出的安排以書面的方式，作為專案團隊成員以及專案干係人之間的共識與約定，專案生命週期內的所有專案活動的行動基礎，專案團隊開展和檢查專案工作的依據。
常見的問題：把專案本身的「專案目標」誤作編制專案開發計畫的目的。
1.2 背景
專案的名稱：經過與客戶商定或經過立項手續統一確定的專案名稱，一般與所待開發的軟體系統名稱有較大的關係，如針對「xx系統」開發的專案名稱是「xx系統開發」。
專案的委託單位：如果是根據合同進行的軟體開發專案，專案的委託單位就是合同中的甲方；如果是自行研發的軟體產品，專案的委託單位就是本企業。
專案的使用者（單位）：軟體或網路的使用單位，可以泛指某個使用者群。注意專案的使用者或單位有時與專案的委託單位是同乙個，有時是不一樣的。如海關的報關軟體、稅務的報稅軟體，委託單位是海關或稅務機關，但使用的使用者或單位不僅有海關或稅務機關，還包括需要報關、報稅的企業單位。
專案的任務提出者：本企業內部提出需要完成此專案的人員，一般是領導或商務人員；注意專案的任務提出者一般不同於專案的委託單位，前者一般是企業內部的人員。如果是內部開發專案，則兩者的區別在於前者指人，後者指單位。
專案的主要承擔部門：有些企業根據行業方向或工作性質的不同把軟體開發分成不同的部門（也有的分為不同事業部）。專案的特點就是其矩陣式組織，一般乙個專案的專案成員可能由不同的部門組成，甚至可能由研發部門、開發部門、測試部門、整合部門、服務部門等等其中幾個組成。需要根據專案所涉及的範圍確定本專案的主要承擔部門。
專案建設背景：從政治環境上、業務環境上說明專案建設背景，說明專案的大環境、來龍去脈。這有利於專案成員更好地理解專案目標和各項任務。
例句：根據《某部關於某建設工作的實施意見》精神，為了保障某建設工作的正常實施，必須加強監督考核，建立督查通報制度，某市某建設工作小組辦公室把此項建設工作實施列入督查的重要內容，及時掌握進度，相關部門建立市某建設工作演示文稿制度，及時反映全市某建設工作動態。
目前對於某建設工作的工作主要採用計畫部門手工編制年度計畫、建設工作主管部門和建設工作實施單位聯合手動編制進度計畫，某建設工作單位手工上報建設工作進度情況的方式，而全市的建設工作有數百個，加上前期建設工作的數量和今後某市建設發展的趨勢，建設工作的數量將越來越多，原來的工作模式已經越來越無法適應市委市**的要求。因此，充分利用現代資訊化、網際網路的優勢，建立「某市某建設工作資訊報送反饋系統」，提高某建設工作資訊報送反饋工作效率，提高資訊的及時性、減輕各級相關工作人員的勞動強度是非常有必要和緊迫的任務。
軟體系統與其他系統的關係：說明與本系統有關的其他系統，說明它們之間的相互依賴關係。這些系統可以是這個系統的基礎性系統（一些資料、環境等必須依靠這個系統才能執行），也可以是以這個系統為基礎的系統，或者是兩者兼而有之的關係、互相依賴的系統。例句：本系統中對外部辦公部分如需要各個建設單位報送材料的子系統應當掛在市****。
軟體系統與機構的關係：說明軟體系統除了委託單位和使用單位，還與哪些機構組織有關係。例如一些系統需要遵守那些組織的標準、需要通過那些組織機構的測試才能使用等等、是否需要外包或與那些組織機構合作。
1.3 定義
列出為正確理解本計畫書所用到的專門術語的定義、外文縮寫詞的原詞及中文解釋。注意盡量不要對一些業界使用的通用術語進行另外的定義，使它的含義和通用術語的慣用含義不一致。
1.4 參考資料
列出本計畫書中所引用的及相關的檔案資料和標準的作者、標題、編號、發表日期和出版單位，必要時說明得到這些檔案資料和標準的途徑。本節與下一節的「標準、條約和約定」互為補充，注意「參考資料」未必作為「標準、條約和約定」，因為「參考」的不一定是「必須遵守」的。常用資料如：
本專案的合同、標書、上級機關有關通知、經過審批的專案任務書；
屬於本專案的其他已經發表的檔案；
本文件中各處引用的檔案、資料，包括所要用到的軟體開發標準。
1.5 標準、條約和約定
列出在本專案開發過程中必須遵守的標準、條約和約定。例如：相應的《立項建議書》、《專案任務書》、合同、國家標準、行業標準、上級機關有關通知和實施方案、相應的技術規範等。
「參考資料」一般具有「物質」特性，一般要說明參照了什麼，要說明在**可以獲得；「標準、條約和約定」一般具有「精神」特性，一般是必須遵守的，不說明在**可以獲得。參考資料的內容應該涵蓋「標準、條約和約定」。
4 實施計畫
4.1 風險評估及對策
識別或預估專案進行過程中可能出現的風險。應該分析風險出現的可能性（概率）、造成的影響、根據影響應該採取的對策，採取的措施。風險識別包括識別內在風險及外在風險。內在風險是指專案工作組能加以控制和影響的風險，如人事任免和成本估計等。外在風險指超出專案工作組等控制力和影響力之外的風險，如市場轉向或**行為等
風險的對策包括：避免：排除特定危脅往往靠排除危險起源；減緩：減少風險事件的預期資金投入來減低風險發生的概率，以及減少風險事件的風險係數；吸納：接受一切後果，可以是積極的（如制定預防性計畫來防備風險事件的發生），也可以是消極的（如某些費用超支則接受低於預期的利潤）。
對於軟體開發專案而言，在分析、識別和管理風險上投入足夠的時間和人力可以使專案進展過程更加平穩，提高專案跟蹤和控制的能力，由於在問題發生之前已經做了周密計畫，因而對專案的成功產生更加充分的信心。
軟體開發專案常見預估的風險：
1) 工程／規模／進度上的風險
規模大，規模估算不精確甚至誤差很大；就規模而言，使用者要求交付期、費用很緊；預料外的工作(測試未完時的現場對應等)；
2) 技術上的風險
使用新的開發技術、新裝置等，或是新的應用組合，沒有經驗；是新的行業或業務，沒有經驗；效能上的要求很嚴；
3) 使用者體制上的問題
使用者管理不嚴，恐怕功能決定、驗收不能順利地完成（或者出現了延遲）；或者恐怕功能會多次變更；與使用者分擔開發，恐怕工程會拖延（或者出現了延遲）；使用者或其他相關單位承擔的工作有可能延誤；
4) 其它：應該包含此處沒有、但據推測有風險的專案。
4.2 工作流程
說明專案採用什麼樣的工作流程進行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己建立的工作流程。不同的流程將影響後面的工作計畫的制定。必要時畫出本專案採用的工作流程圖及適當的文字說明。
4.3 總體進度計畫
這裡所說的總體進度計畫為高層計畫。作為補充，應當分階段制定專案的階段計畫，這些階段計畫不在這份文件中，當要以這份總體計畫為依據。
總體進度計畫要依據確定的專案規模，列表專案階段劃分、階段進度安排及每階段應提交的階段成果，在階段時間安排中要考慮專案階段成果完成、提交評審、修改的時間。
對於專案計畫、專案準備、需求調研、需求分析、構架設計或概要設計、編碼實現、測試、移交、內部培訓、使用者培訓、安裝部署、試執行、驗收等工作，給出每項工作任務的預定開始日期、完成日期及所需的資源，規定各項工作任務完成的先後順序以及表徵每項工作任務完成的標誌性事件（里程碑）。
例如
軟體開發專案計畫書編寫說明
4 實施計畫 4.1 風險評估及對策 識別或預估專案進行過程中可能出現的風險。應該分析風險出現的可能性 概率 造成的影響 根據影響應該採取的對策，採取的措施。風險識別包括識別內在風險及外在風險。內在風險是指專案工作組能加以控制和影響的風險，如人事任免和成本估計等。外在風險指超出專案工作組等控制力和影...
軟體開發專案計畫書編寫說明
軟體開發專案計畫書編寫說明 來自 http blog.csdn.seaskylong archive 2005 06 18 397306.aspx 4 實施計畫 4.1 風險評估及對策 識別或預估專案進行過程中可能出現的風險。應該分析風險出現的可能性 概率 造成的影響 根據影響應該採取的對策，採取的...
C 專案開發編寫專案計畫書
根據 gb8567 88計算機軟體產品開發檔案編制指南 中的專案開發計畫要求，結合單位實際情況，設計專案計畫書如下。1 引言 編寫目的 為了保證專案開發人員按時保質地完成預訂目標，更好地了解專案實際情況，按照合理的順序開展工作，現以書面的形式將專案開發生命週期中的專案任務範圍 專案團隊組織結構 團隊...