專案之所以成立，是因為有需求；然後從需求中，粹選出專案範疇。可以說，專案需求是專案的根本。專案需求沒有確定，專案規劃所計畫出的成本、時程、風險、品質……等等，全都不切實際，也沒有意義。   不順利的一天 沙拉氣沖沖的回到辦公室，一屁股坐下，口中不停喃喃自語：又要變，又要變，到底還要變多少次你才會滿意？自己要做什麼都不清楚，我們怎麼幫你做好？拜託你！可不可以先想清楚再要求我們做，可以嗎？可，以，嗎？   做過專案的朋友們，對這場景應該都不會陌生。是的，專案需求改變了。這是一件很平常的事，有句名言是這樣說的：這世界上唯一不變的真理是，永遠在變化中。因此，當專案資助人（sponsor），不論是客戶、老闆或是業務單位，對專案需求提出變更要求時，實在不需要像沙拉一樣被觸怒；要知道這不是特別不順利的一天，這只是另一個十分平常的一天而已。       專案變更成本 專案需求的影響十分鉅大，而隨著專案進行時間越久，影響會越大。 專案初期變更成本大都侷限在文件的變更，因此主要支出會在人力資源上；而隨著專案的發展，成品雛型漸漸形成，原料、設備、技術……等等各項支出會陸陸續續發生。任一變更，都有可能讓前項已發生的支出化為烏有，全部浪費。   除了有形的金錢以及機會成本之外，還有一項人們少為探究的無形成本，那就是專案團隊的士氣。頻繁的變更，很容易打擊團隊的士氣；更可能養成專案資助人錯誤的習慣，認為專案隨時可以任意變更，最後終將無可避免的導致專案失敗。   專案變更管理 專案需求不是不能變更，要專案需求在專案初期就確定、凍結不變，這也未免太強人所難。既然變更是必然，我們首先在心態上就應先有心理準備，以平常心面對專案變更，不要像沙拉般情緒起伏太大，影響工作、影響生活。我們應該把重心放在三個重點上： 一、如何在專案初期更精準的收集完整且具體不曖昧的需求。 二、如何在專案進行當中妥善管理好專案變更。 三、如何在變更太重大或太頻繁時設下專案終止點。   蒐集專案需求 專案需求很難蒐集完整，這是事實；然而，還是有可能辦到，只要用對的人，用對的方法。所謂對的人，指的是選用正確的領域專家（SME： Subject Matter Expert）擔任商業分析師（system analyst）的角色，負責引導、蒐集、分析及確認需求。所謂對的方法，是指要利用反覆（iterative）蒐集的方式，隨時修正需求，逐步雕琢細緻化。   管理專案需求變更 即便專案規劃時已對需求有足夠清楚地描述，然而，隨著專案進行，發生變更的機會依舊是在所難免。專案需求變更未經好好管理，很容易造成範疇膨脹（scope creep），使得專案越做越多，越做越大，最後變成臃腫的四不像大怪獸，遠遠偏離了專案初始的商業需求（business needs）。PMBOK® Guide教我們可以利用變更控制流程（Change Control Process）來管理好需求變更。基本上，這是對的，也沒問題。專案一開始就昭告天下，需求變更須經過圖二的流程，所有人都應被充分告知。所有變更的執行，都需要事先經過評估，且獲得變更控制委員會（CCB： Change Control Board）的核可。在流程有效管控下，一旦獲得審查核可，變更可以有合理的時間與預算去執行。   然而，專案進行後會發生爭議的點會在－這到底算不算是變更？因為是變更，就要依照流程提出申請，經評估可能對成本、時程、品質……等的影響程度，送委員會審查。如果不算變更，就可以立即進行。坦白說，有些時候還真的很難說得清楚，往往是公說公有理，婆說婆有理，各自表述，互不相讓。記得以前做過一個軟體開發專案，有一個會員資料輸入的功能，其中有一欄是地址。客戶（專案資助人）提出地址輸入完畢，軟體系統要能自動帶出3碼郵遞區號。這算是需求變更嗎？客戶堅持這是屬於資料輸入的功能內，不能算是變更。合理，是吧！但是，一般來說，就常理而言，郵遞區號都是要人工輸入，頂多用下拉式選單，還是要由人工來判斷與選擇適當的郵遞區號，不會是由電腦系統自動挑出正確的郵遞區號。如果要利用電腦系統判讀，那應該是另一個算是人工智慧（AI： Artificial Intelligence）的功能，要算是需求變更。這也說得過去，對吧！往往類似這些主觀上認定的差異，只能依靠雙方平日所培養的互信與默契來解除爭端。   流程中扮演重要角色的變更控制委員會（CCB），如有必要，可以設置多層架構，如圖三。當影響層面太過重大，或是無法達成共識時，可以交由更高階主管再做定奪。   適時提出終止專案 雖然說，需求變更是專案的常態；但也不代表說可以無限上綱過於頻繁的任意變更，或是將專案做大幅度的變更。會發生以上任一種狀況，只有一個可能性，那就是對這專案還沒做好準備，對想要完成的結果還未成形。執意勉強地繼續下去，只是徒然浪費資源，甚至於可能會折損到最珍貴的專案團隊成員。此時，最應該做的事是，立刻停止專案的進行，專案資助人先行釐清期望與目標後，再重啟新專案。   結語 需求變更並不可怕，它不是毒蛇猛獸；實際上，它是讓專案得以更貼近組織利益的手段之一。專案初期不成熟的需求，透過適度的變更可以讓組織獲得最大利益。然而，未經妥善管理，它也可以是出閘的毒蛇猛獸，危害到整個專案，甚至整個組織，實在是不可不慎！       更多精彩內容都在【明華園的專案管理】   各大電子書城 → http://www.pm-mag.net/Magazine/El_bookstore.aspx