Location and Availability:這些人所處的地點是否夠便利,可參與性是否夠高?
這不止會影響你進行需求引出(Elicitation)的方便性,也會影響後續追蹤的時候,會不會把你搞到想砸爛電腦、摔爛電話的程度。當然啦,如果你想換台電腦還是手機,我想你可以盡量去自找麻煩。
上面這些要素其實都只是 BAG 中特別提醒的內容。實務上運作的時候,我相信沒有人會這樣一條條列出來檢視,因為你必須將這些項目內化到心裡,要很清楚找哪些人來參與,才能讓專案順利進行下去。但這時候千萬要記得一件最重要的事:「寧願找能讓專案順利的人,也不要找讓專案完美的人。」
在你整理、分析並整合這份 Stakeholder Analysis Result 之後,在將這份文件提供給 PM、Project Team 和 Sponsor 之前,千萬不要將這份文件先拿給你分析的這些人,好心地要他們幫你看看有沒有什麼地方講錯,這樣的行為就像是拿著炸彈要敵人幫你檢查會不會爆炸一樣,別傻成這樣。
等 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)進行專案, 大部分公司並不會這麼明確地說他們用哪種週期,你得仔細觀察公司其他專案的運作方式,因為通常都是混合著用,所以我們先來瞭解這些生命週期各自的用處和適合的時機:
Identify the Resources:要請這些人完成那些事,需要哪些資源?要記得,人通常都是膽小的,所以他們要求的資源在大部分情況下,一定都會多要一些,原因很簡單,因為這樣才能避免在急用的時候沒有資源了,如果多要了,即使這次沒用上,下次還會有機會用到它,所以寧願多要也不要客氣。在這種時候,聰明的 BA 千萬不要被矇騙了,請務必找可信任(?)的資深人員幫你多看一下,不然到時候資源花費過多的帳,其實會算在你的頭上而不是他們的。
Estimate the Work:最後,綜合其他各種因素,像是工作態度、各相關人彼此間的配合度、最終目標的期望時程等等,一點一點地調整甘特圖的細部內容,直到你自己滿意到覺得可以拿這張圖大聲地跟老闆要糖果..不,是要資源了。
得到老闆們的簽核−Obtain Approval
簡單的六個步驟就把甘特圖,不,是 BA Work Plan 做出來了。然後,你就可以開開心心(膽戰心驚?) 地拿著 BA Plan 和 BA Work Plan 去給 Key Stakeholder 重新看過一遍,然後再找幾個大頭簽核(Key Stakeholder 和 Sponser 必簽),最後帶著必死的決心和 PM 一起上戰場吧。