2009年5月17日 星期日

專案成員對於變更控制程序應有的認知與責任


「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應由專案經理進行協調與掌控。

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

沒有留言:

張貼留言