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

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

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

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

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

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

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

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

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

得到老闆們的簽核−Obtain Approval