[D2] 當你不小心踏入PMI-PBA的陷阱之後，要知道計畫永遠趕不上變化。

2019/07/19閱讀時間約 13 分鐘

完美的計劃，只存在計畫結束後的結案報告裡。

PMI 從 PMP 證照開始，無論進行什麼專案，強調的都是先計畫再執行，並且在過程當中要不斷地監控，直到整個專案結束；因此就如同PMP的五大階段一樣，PBA也有五大領域(Domains)，同樣都是初始、計畫、執行、監控和結案。說實話，也不知道是 PMI 偷懶還是故意的，同樣的架構拿來在不同的證照中使用。

因此，當我們在初始階段(D1)拿到老闆簽核的商業提案書(Business Case)之後，我們接下來的面對的才是真正的殺戮戰場。

重新整理關係人清單−Conduct or Refine Stakeholder

別以為在製作提案書的時候，聽到的那些抱怨、問題以及彼此爭奪的資源，還有一堆狗屁倒灶的事終究告一段落，而你終於可以安心地開始執行後面的所有計畫了，這麼順利的事基本上只有在夢裡面才會見到，不過我想當你做 BA 工作久了，能做這樣的夢恐怕也是像奇蹟一樣。

不管是哪間公司、哪個專案，資源都是由人所控制的，因此BAG Chapter 3 (Domain 2，簡稱 D2)中最重要的第一件事，就是要你回頭重新審視你所找的 Stakeholder 是否正確。而且，無論你是用 Brianstorming 還是用組織圖去看，你還得同時注意下面這些事：

Attitude：所找到的人對專案的態度是什麼？他們的支持度高嗎？
支持度高的，你要了解為什麼他們支持。支持度低的，更要了解為什麼他們反對，當然啦，想從這些人口中挖出「為什麼」，那可是要花費比吃奶還大那的力氣，甚至要來一番爾虞我詐才挖(套)得出來。
Complexity：這些人加入後會對專案提高多少複雜度？
人越多，事情就越複雜，但是人不夠多，瞭解得就不夠全面，不同專案有不同的需求，你得看手上的專案本身的複雜度，來決定究竟要找哪些人，通常來說，只要直接牽扯到跨部門、甚至跨地區的人，那就絕對簡單不起來。
Culture：他們各自的文化習慣會不會引發衝突？你該用什麼角度和他們合作？
譬如說：若團隊中有伊斯蘭教的同事，你得知道開會時間千萬不要安排在他們每日禮拜的時間，不然你一定等著每次開會他們都不在的窘境。
Experience：這些人的產業經驗多或少？
不一定多才是好，有時候固執的主觀想法反而造成專案窒礙難行，更不用說通常老闆都聽經驗多的人的話，如果碰上一個經驗豐富、受老闆信任但想法固執的老油條，這個專案到最後是生還是死，其實全部掌握在這根油條手上。
Influence：你找來的這些人對整個專案的影響力大或小？
「影響力越大、責任越強？」這句話根本是個天方夜譚，影響力越大通常在出了問題之後，逃得越快，因為他也可以影響逃亡的路線只為他一個人所開。
Location and Availability：這些人所處的地點是否夠便利，可參與性是否夠高？
這不止會影響你進行需求引出(Elicitation)的方便性，也會影響後續追蹤的時候，會不會把你搞到想砸爛電腦、摔爛電話的程度。當然啦，如果你想換台電腦還是手機，我想你可以盡量去自找麻煩。

上面這些要素其實都只是 BAG 中特別提醒的內容。實務上運作的時候，我相信沒有人會這樣一條條列出來檢視，因為你必須將這些項目內化到心裡，要很清楚找哪些人來參與，才能讓專案順利進行下去。但這時候千萬要記得一件最重要的事：「寧願找能讓專案順利的人，也不要找讓專案完美的人。」

在你整理、分析並整合這份 Stakeholder Analysis Result 之後，在將這份文件提供給 PM、Project Team 和 Sponsor 之前，千萬不要將這份文件先拿給你分析的這些人，好心地要他們幫你看看有沒有什麼地方講錯，這樣的行為就像是拿著炸彈要敵人幫你檢查會不會爆炸一樣，別傻成這樣。

所以，就算沒拿給被訪談者們(Stakeholder)看，也千萬要注意一件事：不論你老闆們再怎麼保證不會洩漏給任何人知道，也絕對別在分析報告中說任何人的壞話…不然的話，我想你自己也應該很清楚，如果那樣做的話，接下來的整個專案中你會絕對不好過。

所以該怎麼辦呢？我通常都會建議這個分析文件根本不用寫太多，只需要寫上人名以及他可以做的事就好，其他廢話不要寫，反正在專案進行的過程當中，如果有任何問題，也是要即時處理，現在想太多其實根本沒有什麼用。

開始撰寫商業分析計畫書−Business Analysis Plan

等 Stakeholder 再次地重新被我們綁架進專案之後，就進入 D2 的兩個重頭戲了：商業分析計畫書(Business Analysis Plan，簡稱 BA Plan) 和商業分析工作計畫書 (Business Analysis Work Plan，簡稱 BA Work Plan)。這兩個名詞看起來很像，而且根本就只差個 Work一字而已，但裡面的內容可是天差地別、完全不一樣。

根據過去的經驗，很多人看到 BA Plan 這個章節的時候，會以為這裡講的是實際開始 Analysis 了，其實這樣的說法誤會大了，因為這裡都還只是在規劃而已，也就是說 BA Plan這個章節，只是寫出「如何分析的規則和計劃」而已，還沒有開始真正進行分析，真正的分析其實是在 PMP 中的 Excuting 流程群組中。

在開始規劃的時候，當然得看你們公司或團隊打算採取哪種專案生命週期(Project Life Cycle)進行專案，大部分公司並不會這麼明確地說他們用哪種週期，你得仔細觀察公司其他專案的運作方式，因為通常都是混合著用，所以我們先來瞭解這些生命週期各自的用處和適合的時機：

Predictive－預測型：傳統的說法是瀑布式。
也就是完全按照計劃1, 2, 3, 4地一步一步走。以蓋一棟百貨大樓為例，就是先把每一層樓的功能、商家全都計劃好、談好了，然後才開始蓋大樓。從這個例子來想的話，我應該就不用解釋太多了，只要是一切事情都能夠如預期進行的話，那就適合這樣的週期方法，但我們都知道現在的世界沒那麼簡單，所以這樣的做法也漸漸地被淘汰，或是融合以下兩種做法了。
Iterative/Incremental：漸增式，作法介於 Predictive 和 Adaptive 之間。
同樣以百貨大樓來說，這方法先規劃好要蓋百貨大樓，並且也真的蓋好了之後，再來決定每一層樓的功能和商家，然後才去一個個商談、一個個根據他們各自的需求，對每一層樓的細部功能重新調整並建立。
這個週期最適合已經有初步規劃，但細節必須由合作廠商製作才有辦法決定的專案，目前來說，這樣的生命週期也比較貼近尚未完全轉型成 Adaptive 型態的公司，而且多半的情況下也是兼具彈性和執行力的一種。
Adaptive：調適式。這個週期非常接近 Agile，甚至某些施行 Agile 的團隊，其實是用這個方法。
這個方法是最彈性、但也對即時反應和自主運作的要求最高。這就像是想蓋百貨大樓，就先蓋好第一層，然後在規劃功能和招商的同時，看營運的情形，再決定是否往上蓋其他樓層、增加其他功能。
這個週期方式最適合所有情況未定，但整個團隊都非常清楚該往哪個明確方向前進的專案。雖然兼具彈性和執行力，但對團隊中彼此的信任感、團隊向心力、成員自主行動和協調溝通能力要求極高，在這幾點未能達到一定水準之前，千萬不要貿然全面採用這個方法，否則你只會等著看到整個團隊各行其是，甚至互相抱怨了。

在 BA Plan 的規劃過程中，其實唯一要注意的就是上面這三種 Life Cycle 而已，因為這三種生命週期會影響整個分析行程的安排。

接下來事情就簡單了，在 BAG P.55 到 P. 60 描述得非常清楚，你只需要根據公司的文化和既定的規則，建立起每個流程所需要的規則就行了：

一開始，我們得先將需求排序(Requirement Prioritization)
然後為了能夠追蹤(Traceability) 每個需求的執行結果，
我們必須了解如何和所有人溝通(Communication)，
溝通完之後，必須要能對結果做出決定(Decision-Making)，
有了決定，就要反過頭來對需求驗證和確認 (Verification and Validation)，
如果 V& V 之後，有東西需要變更 (Requirement Change)就要去監控變更，
當一切都完美(?)地結束後，就可以對解決方案作最後評估了 (Solution Evalution)。

對，就這麼簡單幾句話，就講完從 P.55 到 P.60 的所有事情。

不過，要記得這些是在規劃中的思維模式，它們不一定是實務上會進行的步驟，並且一定要記得你現在只是完成了規劃，而不是真的開始下去執行，執行的工作不關你的事，那是 PM 該做的工作。嗯…好吧，你在台灣，所以你可能也是 PM。

接下來是真正有用處(?)的工作計畫書−Business Analysis Work Plan

當我們辛辛苦苦在倉庫翻遍舊資料、參考過去案例，並且用盡力氣完成 BA Plan 之後，就要開始規劃真正執行工作的計畫表了。BAG 裡稱呼它是 BA Work Plan，但我比較喜歡稱呼它是 BA 甘特圖。為什麼？很簡單嘛，當你畫甘特圖的時候，不就依照以下的步驟去畫嗎？

Identify the Deliverables：首先，我們決定要產出什麼？
Tasks and Activities：然後將產出(Step 1)作為大項目，並且在底下拉出中項目和小項目，這些大小項目就是要做哪些 Task 和 Activity才能產出此大項目。
Timing and Sequence：知道有哪些 Task 和 Activity 之後，我們得預先猜想中小項目所需要的時間，以及它們之間的關聯性，並藉以安排執行的順序。
Roles and Responsibility：當安排完 Task 和 Activity 之後，要找到可以做這些工作的人，並且明定他們的責任是什麼，當然啦，這時候通常還會順便再問一下這些 Task 和 Activity 的時間和順序是否符合他們的想法，如果不對，就參考他們的建議修訂；如果都對，那麼你最好皮繃緊一點，因為通常這是不可能的事，一定有問題。
Identify the Resources：要請這些人完成那些事，需要哪些資源？要記得，人通常都是膽小的，所以他們要求的資源在大部分情況下，一定都會多要一些，原因很簡單，因為這樣才能避免在急用的時候沒有資源了，如果多要了，即使這次沒用上，下次還會有機會用到它，所以寧願多要也不要客氣。在這種時候，聰明的 BA 千萬不要被矇騙了，請務必找可信任(?)的資深人員幫你多看一下，不然到時候資源花費過多的帳，其實會算在你的頭上而不是他們的。
Estimate the Work：最後，綜合其他各種因素，像是工作態度、各相關人彼此間的配合度、最終目標的期望時程等等，一點一點地調整甘特圖的細部內容，直到你自己滿意到覺得可以拿這張圖大聲地跟老闆要糖果..不，是要資源了。

得到老闆們的簽核−Obtain Approval

簡單的六個步驟就把甘特圖，不，是 BA Work Plan 做出來了。然後，你就可以開開心心(膽戰心驚？) 地拿著 BA Plan 和 BA Work Plan 去給 Key Stakeholder 重新看過一遍，然後再找幾個大頭簽核(Key Stakeholder 和 Sponser 必簽)，最後帶著必死的決心和 PM 一起上戰場吧。

就這麼簡單，寫計畫難嗎？不，其實只要短短一篇文章就講完 Domain 2 該做的事了，也許有些人會覺得怎麼可能會這麼簡單？當然，事情永遠不會這麼簡單。

在規劃的過程中，其實所有的苦全部都落在 BA 身上，因為你得從無到有想辦法生出一個可能沒人想過的分析計畫，而且要寫出一份讓老闆們像是看到黃金般眼睛一亮的計畫，在這過程中，你所遇到的所有挫折、質疑、烽火交錯、披巾斬棘、爬過的天堂路，是沒有人會在乎的，因為你是 BA(也可能兼任PM)。

如果你運氣好，已經有前輩吃過苦，也許可以從過去的文件中挖出一些歷史秘辛，但請相信我，那些都是過去式，你現在面對的是全新的專案、全新的局面，而站在戰場上的人其實只有你一個。

對，沒有 Project Team、也沒有 Support Team，對，因為你是 BA，頭最先洗下去的第一個人就是你。

就像搶第一的人一樣，成功或失敗全靠你的心臟夠不夠大，毅力夠不夠堅強，還有運氣夠不夠好，當然，老闆挺不挺你，通常就是最後的成敗關鍵了。

如果這篇文章你想用聽的，可以在這裡找得到：
https://www.ears.tw/sounddetails/1745

如果你覺得這篇文章不錯，值得拍拍手，也可以拍五下 Like 給我一些鼓勵：

為什麼會看到廣告