gipi的學習筆記-經營管理、數據思考、終身學習

原文亦刊載於《專案經理雜誌》

延續上一篇，本篇我們繼續來談談專案中的六種會議以及四種溝通類型：


啟動會議(Kick-off Meeting)
這通常是專案成員的第一次正式會議，但在實務中很多的PM會忽略了這個會議的重要性，以為只要任務佈達了，相關的人員就會動起來，這其實是個很大的認知錯誤，在起步階段，專案成員對於專案的目標以及自己扮演的角色是不清晰的，成員之間也尚未有任何的默契，啟動會議在此就扮演了重要角色，一般來說該會議應該完成以下事項[註1]：
1. 邀請專案的利害關係人(Stakeholder)參與，包含Sponsor、專案成員、客戶代表、需求提供者等人參與
2. 說明專案的目的、範疇、限制
3. 說明專案主要的里程碑
4. 介紹專案中的成員(包含主要Stakeholder)，並說明每個人擔任的角色
5. 說明專案執行計畫書(PEP)中的內容[註2]

透過這個會議讓大家了解專案，對專案的目標commit，許得相關人員的承諾，並讓團隊成員彼此熟悉，讓資訊開放、透明，這可讓專案成員們更安心與投入。

啟動會議的溝通類型是取得承諾，功能性部門主管承諾，會在正確的時間點投入正確的資源來完成專案任務；專案成員承諾專案範疇內的任務在技術上、時程上是可以達成的；Sponsor承諾對專案的支持與投入，這些承諾不是喊喊口號，而是必須要認真的思考後做出的承諾，否則只是唱高調，說都沒問題，但無法做到。而對於有些無法在會議中立刻做出承諾的事項，PM後續也該持續追蹤，直到能做出承諾為止。

里程碑會議
在超過一定時間或者複雜度的案子，一般我們都會設定一到多個里程碑，而里程碑達到時也會召開里程碑會議，一來是對Sponsor報告專案的進度與健康狀況，並將這段時間完成的內容做交付的動作，或許可以當成專案的期中報告；二來也是跟團隊成員們進行Lesson Learn的好機會，檢討這段時間哪些地方做的好，哪些地方做不好，這些都可以作為專案往下的重要參考。

決策方案會議
當專案進行過程中出現需要做技術選擇、需求取捨、風險規避時，總會因此衍生出各種變更的可能性，例如選擇A技術，在人力資源的取得較難，但專案開發時程可以縮短；選擇B技術，人力很容易招募，但相對的開發時程就比較長；直接購買C工具，成本多出兩百萬，但不用自行開發，招募的人手也因此減少了。在上述狀況下，因涉及了專案金三角的變更，因此在專案中扮演的角色也很重要，在召開這會議時千萬要請PM準備好三種以上備選方案，並比較其優劣與影響性，然後針對專案目前的狀況提出你的建議方案，就算Sponsor有不同的考量點，他也很清楚他有哪些方案可供選擇。

決策方案會議的溝通類型是決策，也就是會議最主要的目的是要決定接下來該朝什麼方向進行，這是決定專案命運的分水嶺，如果你前期評估做的不夠仔細，可能在決策會議時就會做了錯誤的決定，或者會議中無法決定，Sponsor要你再做評估，此時你犧牲的不僅僅是時間，也是你自己作為PM的credit，所以在準備資料時，一定要想著「這個會議一定要做出決定，而我準備的資料一定可以協助大家在會議中做出正確的決定。」

例行性會議
就名稱上來看，很多人會把這會議當成一種形式，但其實例行性會議可能是專案中最重要的會議，專案團隊多久開一次會？每次會議時間多長？討論些什麼？這通常是我在衡量專案狀況的重要指標之一，有些團隊一個月開一次會，有些一週，有些則一天，週期視專案的形態會有所不同，但我個人建議例行性會議最少每週需要召開一次，因為它扮演的角色是資訊同步。

例行性會議可以讓團隊成員們了解目前專案的狀況，讓大家有參與感，讓大家感受到專案的壓力與進展，體會專案前進的感覺，也讓大家多多交流培養默契。曾看到有些跨部門專案，在專案啟動後不曾開過例行性會議，結果只知道前置工作有延遲，但不知道為何延遲，延遲多久，所以也不清楚自己何時該投入，更甚者就直接等待別人通知才準備動工，試想在這樣的狀況下，專案能不延遲嗎？除了固定的Team building活動外，例行性會議其實也是一個很好的team building機會，千萬別讓它流於形式。

例行性會議的召開要維持一定的頻率，但時間可以不用太長，重點放在執行狀況有異常的部份即可，會議中不需要針對每一項工作做檢討，把時間花在要大家留意、配合，或者變更上，簡單扼要，但傳達必要資訊，也告知明確方向，讓大家能安心的作事。

結案會議
如果Sponsor願意參加結案會議，通常代表他對專案的結果尚感到滿意，所以結案會議大概也不會開的太痛苦，但其實結案會議就像是PM的專案成果報告，專案做的如何其實從專案會議就可以做一個徹底的檢視，也因此，結案報告是必須要經過適度的包裝的，所謂的包裝不是浮誇或者造假，而是據實以告，如果專案過程因為有許多的變更產生，導致專案時程往後延，所以過程中的SPI一直不是太漂亮；或因為縮短專案交期，所以刪減了部分功能，導致功能完成比例只有90%，這些應該都要做適度的補充，不著痕跡的去喚起Sponsor的記憶，以免大家只關注於結果，但忘記了過程。

結案會議有時也是一個很好的感恩場合，感謝團隊成員的付出與辛勞，感謝Sponsor的支持與配合，讓案子能順利結掉。而對案子的檢討自然也要帶到，除了為自己累積經驗外，也有助於強化專案團隊經驗以及下一次的合作默契。

變更管理會議
「專案管什麼？管變更。」

幾乎所有的專案都涉及變更，所謂的變更可能是專案金三角，也可能是人力資源、規則、法令等等，只要會影響到專案進行，必須要面對的，都可能有變更的需求，而一定規模的變更就需要召開變更管理會議來做討論，並依議題的重要性決定是否請Sponsor出席。

我認為PM應該抱持著「變更是必然會發生」的心態去面對變更這件事，並以以下的動作來處理變更[註3]：
1. 首先你必須了解這項變更的原因
2. 接著是評估影響的範圍(包含範疇、時間、成本、品質等)
3. 再來則是識別此變更是否必要
4. 核准、拒絕、暫緩變更
5. 對核准過且影響不大的變更，專案經理自行決定是否執行即可；若影響的範圍較大(影響到範疇、時間、成本)，則必須經過專案經理、Sponsor等共同決定是否執行變更
6. 將專案的變更記錄下來，不管這項變更最後有沒有執行(用來做紀錄與稽核)

變更管理會議的溝通模式是決策與共識，大多時候是PM與團隊成員或Sponsor之間取得共識，並讓案子能順利的往下進行，如同決策管理會議般，PM準備的資訊愈充足，決策的品質愈高，也愈有機會達成共識。

上一篇專欄中我曾說過如果你不清楚會議的目的，代表你根本不應該開那個會，本文中介紹了六種會議，希望讓各位PM們了解每個會議背後的意涵，也讓大家更清楚如何開好一個會。

備註：
註1：參考「專案啟動會議」(http://www.dotblogs.com.tw/jimmyyu/archive/2010/10/13/kick-off-meeting.aspx)
註2：參考「專案執行計畫PEP」(http://www.dotblogs.com.tw/jimmyyu/archive/2010/09/05/project-execution-plan.aspx)
註3：參考「專案管什麼？管變更」(http://www.dotblogs.com.tw/jimmyyu/archive/2011/12/31/change-management-2.aspx)

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。