從10/6起，我陸續介紹了專案管理計畫所包含3個基準和12個子計畫，包括
10/6 ~10/7 專案管理的3個基準—範圍基準、時程基準、成本績效基準
10/9 範圍管理計畫、時程管理計畫、成本管理計畫
10/10 品質管理計畫、流程改善計畫
10/11 人資計畫、溝通管理計畫
10/12~10/13 風險管理計畫
10/14 採購管理計畫
今天要繼續介紹剩下的3個子計畫—需求管理計畫、變更管理計畫和建構管理計畫。這3個子計畫分別說明在整個專案生命週期內，如何分析、記載以及管理需求；界定需要納管的「建構項目」和需要正式變更控管的內容，並為這些建構項目和內容制定變更控管流程；以及界定專案變更管理流程。

許多專案失敗的主要原因都是因為顧客需求之變更過於頻繁，通常是一開始時賣方便宜行事，沒有慎重地和買方做好溝通，按照需求管理計畫來管理顧客的需求，就急著開工；等專案進行到一半時，顧客發現這不是他要的系統，於是便提出需求變更。此時如果按照顧客意思改，專案必定無法如期如預算完成，可是如果不答應需求變更，那鐵定是無法驗收。所以從專案管理的角度，必須有一個需求管理計畫來分析、記載以及管理需求。內容包含：
如何規劃、追蹤、以及報告需求活動
建構管理活動
需求優先順序
產品度量標準
追溯結構

為了避免顧客在專案進行中途變卦，所有需求都必須納入需求追溯表監控。需求追溯結合需求至其原出處，並在整個專案生命週期中追蹤它，透過將它連結至業務和專案目標來確保每一個需求具有業務價值。內容包含：
追蹤需求至業務需要、機會、目的、以及目標
追蹤需求至專案目標
追蹤需求至專案範圍/WBS交付項目
追蹤需求至產品設計
追蹤需求至產品開發
追蹤需求至測試策略和測試情境
追蹤高階需求至細部需求

控管需求範圍變更的2個管理計畫為變更管理計畫和建構管理計畫。變更管理計畫界定專案變更管理流程，買賣雙方事先規範哪些人哪些事哪些時候可以提出變更申請，以及變更申請處理程序。如果計畫會因為老闆的一句話或是顧客的一通電話做變更，那就是變更管理計畫沒落實。

最後，建構管理計畫界定專案需要納管的「建構項目」和需要正式變更控管的內容，並為這些建構項目和內容制定變更控管流程。所有建構項目必須配合建構管理計畫做簽入/簽出管制，通常專案的3個基準和12個子計畫都是建構項目。

iT鐵人賽只規定
1.先到鐵人賽活動頁報名，寫下挑戰的組別、主題和主題簡介
2.發表文章必須使用鐵人賽專用的發文介面
3.在iT邦幫忙連續發表30天的文章不中斷
4.可以先報名，不用馬上發表文章，但是一旦發表文章後，就不能停、不能停、絕對絕對不能停，一直到第30天
5.最後一天的報名期限是10月13日，超過了這天，就無法在活動結束前完成30篇文章

基本上這樣的需求並不夠嚴謹，真得當天想不出好內容，參賽者可以先找替代品頂一頂；只要不違背上述需求，在參賽的30天內，都可以隨時修改發文內容。評審所審查的內容應該只是最後的產品。因此本專案的變更管理計畫和建構管理計畫就比較彈性。

請問iT人，您參與過無數專案，可曾見過或撰寫過變更管理計畫和建構管理計畫?
(第30之15篇完)

Hold 30天鍊成PMP鐵人 系列連結
上一篇http://ithelp.ithome.com.tw/question/10076185
下一篇http://ithelp.ithome.com.tw/question/10076685