PMP達人-專案管理經驗成長與學習 IT肥蝦個人的專案管理經驗與心得記事與分享。

67愛的鼓勵 2訂閱站台

「Change Control Plan Preparation Guidelines」讀後感
原文：http://www.pm-i-study.net/dis/redirect.php?tid=127&goto=lastpost#lastpost

看了【專案管理交流論壇】成員Miller所上傳的「Change Control Plan Preparation Guidelines」後，肥蝦心中有一些想法，想提出與各位分享。

說實在的，「Change Control Plan Preparation Guidelines」是一篇不錯的變更管理計劃的範本，搭配文章中所提到的「Change Log」、「Status Report」、「Change Request Form」可以成為一個變更管理、監控與追蹤的完整架構。

文章中的章節－本文目的(Purpose of Document)、變更控制程序目標(Objectives of Change Control Process)、名詞定義(Terms, Acronyms and Abbreviations)、變更審核權限(Approval Authority for Changes)、變更控制委員會(Change Control Board)、變更控制程序(Change Control Process)、角色與責任(Roles and Responsibilities)－也是一般所常用到變更控制計劃的節次。各位讀者可以細讀這一份這11頁的指導手冊，相信可以有一個完整明確的瞭解。

肥蝦此時所要闡述的是，個人對於專案團隊成對於變更控制程序所要參與的程度，以及相關的權限設定。

在「Change Control Plan Preparation Guidelines」乙文中主要陳述專案經理(Project Manager)、專案贊助人(Project Sponsor)、變更控制委員會(Change Control Board)，與變更控制委員會之上的指導委員會(Steering Committee)的互動與分工。文中並依據專案的大小與複雜程度，提供了假想的【簡易】與【比較複雜】的兩個層次。但文中就如PMBOK一般，並未對專案成員對於變更控制程序的參與程度，以及有關的權限多所著墨。

肥蝦也仿照該文的【簡易】與【比較複雜】的假設，提出個人認為專案成員對於變更控制程序的可能作法。
(一) 【簡易】
假設：系統分析、設計與程式人員，並未直接與使用者面對面溝通需求。

在此假設下，專案經理應設法瞭解客戶的需求背後目的與理由，協助客戶擬具變更的目的與要項，再請系統分析、設計與程式人員就需求提出意見與建議解決方案。如果專案經理並未具有相關的技術與商業邏輯能力，應先設法尋求團隊成員的協助。在客戶與專業的團隊成員間，扮演一個完善的中介界面，儘量設法不加入自我的主觀判斷。

(二) 【比較複雜】
假設：有專屬的需求分析人員，直接與使用者面對面溝通需求。

在此條件下，需求分析人員應先設法釐清變更後面的動機與原因，並由需求分析人員擬據與客戶討論過的解決方案。再經由填寫「Change Log」、「Status Report」後進行變更控制的流程。如果需求分析人員能自行處理，則專案經理僅需要經由以客戶具名填寫的「Change Log」，以及專案成員填具的「Status Report」的review與檢驗，確認客戶的需求是否有效的滿足；如果需求分析人員無法自行處理，再由專案經理、需求分析人員，與客戶進行溝通，瞭解客戶的真正意圖，確認需求分析人員的分析與建議後，請客戶在需求分析人員協助下填寫「Change Request Form」，再依據該文的流程處理。

此外，「Change Control Plan Preparation Guidelines」中以對專案預算與時程影響程度比例，為介定權責歸屬的依據。這雖然也是一個參考準則，肥蝦也建議就每個activity、work package的角度以及buffer與reserve的owner權限著手。

如果一個要求僅限定在特定的activity或work package，不影響到別個activity或work package的owner所定義的資源、要求與條件，原則上專案經理應尊重每個activity或work package owner的判斷與建議；如果影響層面牽涉到不同的activity或work package owner應由專案經理進行協調與掌控。

肥蝦所繪製的流程圖可加入原文的前半，以為更完善的變更控制程序流程圖。以上肥蝦的看法與作法，還請  各位先進給予指教與建議！