Ocean PMP BLOG

未來的事無法預知, 所以我們必須先要將某些變數先給予假設(assumption)將其固定下來, 才能基於這些假設開始進行計畫, 例如某產品的銷售量, 原料價格, 匯率, 產量, 辦活動要預估來客數, 氣候, 其他如預估時間,運費成本, 需求, 可靠度, 行為模式(pattern), 競爭者狀況, 法規變動,  etc.
以最近發生的88水災來說我們是根據氣象局預測做為假設, 來準備個人行程或防災應變計劃, 可是當氣象局不斷的將雨量上修時, 相對的當初的假設已不正確, 所以後面的計畫如果沒有修正, 當然也無法應付未來環境的變化, 再提醒所有的 forcast, estimation, Assumption 都有 Risk,  都要擺到 risk register 裡追蹤, 看當初的假設還是不是真, 預估是否正確專案計畫是否要更新.
Ocean

Just completed a round of in-house project management training last week. In the course of trainnig I encouraged trainees to see things from the aspect of Project base. In other words, keep in mind PDCA cycle. Plan, Do, Check, Action. It's very easy to realize and memorize. You got used to adapt WBS and network diagram rather than To-Do list. Major task is often involved with stakeholders who you have to deal with and to find out their requirement then plan in. Anything happen against baselines(scope/time/cost/quality)what you feel is "problem" or treat it as a "change request".
Put it together, Project base thinking is Management thinking you have to
1) dig out sponsors' requirements
2) identify stakeholders' needs and wants and expectations

其實賣方規劃單位在開規格時常會考慮未來年幾年的需求，而這些需求有的已有標準，有的還在構想階段，為了能夠在未來競爭環境中能夠繼續生存下來，所以就把一些先進地需求規格列入RFP中(request for proposal)，事實上買賣雙方都知道不一定在結案前能夠將功能做出來(有些標準都還在制定中怎麼會有產品)，這時專案要執行最後階段範疇驗證時就會出問題，但是總不能因為幾個功能就讓整個專案持續延遲下去，下列是各項可能解決方案，這些由賣方提出的 change request都需要走 Integration change control process，先厘清變更的範疇(clarification)、變更的原因(root cause)、對專案範疇、時程、成本、品質、風險的影響(evaluation)，經評估後可能有下列選項可執行，不要讓專案持續的延持無法結案(lose,lose):

花了半個月把 Initiation 寫完了，總共約 15 篇，依專案管理五大流程的順序，接下來應該談到 Planning，因為上星期公司裡的PMP有個聚會，剛好談到要如何應付客戶需求持續變更的問題，所以在談 planning前我們先跳到 Monitoring&Controlling 流程裡最重要的章節 integration change control(整體變更控制)。
話說當某個 change request 被提出後，他對專案目標的影響會僅侷限於單一一個領域嗎？還是須先經由專案團隊先作評估到底影響有多大，再由 change control board 來審查是否同意，舉例來說，IT收到內部需求要建立一個資訊傳遞管理系統，取代目前透過e-mail更新 Excel file 的機制，當你的專案成員完成需求分析、SA(系統分析)、SD(系統設計)後開始進行 coding到一半時， 這時 End user跟你提出要增加一個欄位，這時如果你是專案的 team member你該如何？我知道大部分非 IT base 的 end user的說法:「不就只增加一個欄位，應該很簡單，你計較什麼，幫忙加一下」， end user會把增加欄位這件事，想成與在 Excel file 按右鍵新增一欄一樣簡單，你要是沒有想清楚，礙於人情義薄雲天的一口答應，那麼鐵定是災難的開始，標準的 Scope creeping，寫不完的程式，人家在休假，你在加班。
為什麼這樣說，因為我在公司就負責一個這樣系統，我是 End user 與 IT 之間的窗口，個人有深刻感受，我們來看看增加一個欄位會影響多大，假設該系統有 20個步驟，每個步驟需要讓不同部門人員來更新再傳送至下一部門，另有10個可供相關單位查詢進度資訊的畫面，20支報表，還有一些運算做告警及 KPI 達成率分析，增加一個欄位你說變動有多大，單單重新分析20個步驟、10個畫面、20支報表，還有那些運算機制是否與該欄位相關，可能就要花掉一個星期，這就是為什麼要有 integration change control流程，當你完成評估後，要記得估出所需更動的範疇有多大(scope)，需要多少 manpower (cost)，要多少時間(time)，最後一定要再給一張 Quotation讓 management 及End user了解變動有多大，是否還要變更。每次上課講到這個案例時，IT base的學員都會頻頻點頭，身有同感。
Ocean
 
 
 

專案經理要具備那些特質及知識
記得在七、八年前有一次，我的老闆把我們幾個PM找去談這個問題，在白板上寫了一堆，現在當然不記得，下列是我個人的說法及理由。
1. 特質
1) Responsibility: 專案成立都有其特殊性及重要性，所以找一個有責任感的人是第一要件。有責任感的人通常伴隨著有積極、認真的態度。
2) Integrity: 我們說要將真實的情況反應給管理階層、客戶及專案成員，這通常是需要道德勇氣，才能將專案狀況確實(accuracy)、完整(completeness)、準時(on time)的反應。
3) Organized: 開會討論時專案成員一個個表達自己的意見，這時要看專案經理的組織性夠不夠，能否將眾多意見有邏輯的、有組織的做出總結，而且不偏離主題，讀書時的作文練習就是很好組織性的學習，上班後要看一個人的組織性好不好，讓他去做會議記錄就可以看出，另外Presentation亦可。
4) Creativity: 專案不像 routine job 大部分問題都可掌握，還記不記得專案的三種特質(Temporary、 Unique、Progressively elaborated)，其中Unique 就代表頭一回的意思，所以風險高 issue 多，解決問題除了固定 problem solving 那些 hard skill 之外，alternative solution 通常源自創造力，看看能不能跳脫即有框架。有時後會開玩笑那些不遵守規則的人，最適合做流程改善
5) Friendly(open minded): 90%時間專案經理花在溝通上，如果專案經理個性不是很隨和友善，在溝通上會很辛苦的。
2. 知識
除了九大知識領域之外，一般管理者的職能 competence 或 skill 也要具備 (請參考另一篇 what's differences beteween skill and competency)
Leadership
Legal term&condition
Customer oriented
Team work
Motivation
Problem solving
Decision making
Humanity
Accounting
Financial analysis
Presentation and reporting
Chair meeting
最後如果你什麼都不想記，只要給你一個 role model 讓你可以去學習就可以，那麼 “媽媽”就是最好的 role model，有一天如果你能做到這個程度，你鐵定會是個非常成功的PM。我認為女孩子天生就是做 PM 的料(請參考另一篇文章"女孩子天生就是做 PM 的料")。
Ocean

Preliminary Project Scope Statement初步專案範疇聲明這在上一版沒有，有可能在下一版會消失，所以大致上能夠了解即可，通常來說專案team本身是專家或者說賣方是專家，相對的Management或買方(customers)描述的，都是以他們熟悉的語言簡要的來描述他們的需求(requirements, needs, wants)、關切，這些需求、關切包括產品描述、專案目標、風險提醒、會議頻率、報告格式、是否要 prototype….這些描述就是專案經理與客戶之間對於專案共同的理解(客戶的語言)，稱之為Preliminary Project Scope Statement初步專案範疇聲明, 專案經理事後要透過 Core team在 Scope definition 這個流程裡，將這初步專案範疇聲明經由產品分析(Product Analysis)及尋找不同方案(Identify Alternatives)轉成專業的描述, 來達到初步專案範疇聲明裡的範疇，讓Project team, vendors, supplierss能夠明確瞭解, 我們稱為 Scope statement.
譬如說客戶的需求"某些網頁只能夠開放給特定的人"記載在初步專案範疇聲明裡, 專案team就可透過要產品分析(Product Analysis)及尋找不同方案(Identify Alternatives), 找到最適合的方法來達到客戶的需求, 這個方法就會記錄在Scope statement裡, 如何實現這個方法就是專案要做的事(WBS)
 所以初步專案範疇說明的主要目的是要讓專案經理與專案發起人之間對於專案範疇有共同的理解或交集

Time、Cost、Scope是大家熟悉的 Triple Constraints，在有限的時間內，用有限的預算，要完成交付的範疇。這裡強調”有限”和”交付的”都在限制你專案團隊的選擇或者說彈性，也就是因為有這三重限制才需要成立專案，找專案經理組織專案團隊來解決問題，如果沒有三重限制的事就不叫專案，因為一點壓力都沒有幹嘛要成立專案，可以 Free Run。有時在跟 team member review 專案時，會有完工時程不知道情況，我就會很疑惑問這需要專案控管嗎?
專案的限制除了三重限制外是否還有其他的限制，在做專案計畫除了要意識到 assumptions外，constraints也是重要的一環，舉例來說 證券行要施工得要等到下午1:30後，飯店Lobby 施工要避開 Check in 時段，還是某段時間客戶某個人請假無法做測試，諸如此類這些限制都侷限專案的選擇性，也因為此所以專案可以施工的時間會減少，而可能導致會無法on schedule，為了要解決這個問題，就會要增加工班或加班，這又會衍生其他問題，所以一但有 constraints被identify 出來，全部都應該列入風險登記簿(Risk register)裡作風險回應，所有 constraints 都是風險，這是考題，實務上就要看這個團隊有沒有 Sense可以意識到 constraints的存在。在Stakeholder identified之後，好好瞭解他們的需求，訪談過程中專案會了解許多 constraints(這部分在 identify stakeholders談過了，不再贅述)，要記得所有 constraints 都是風險，全部都應該列入風險登記簿(Risk register)裡作風險回應。
Ocean
 
 
 

我們說Plan就是計畫在先，專案尚未進入執行階段，所以我們是以現在的觀點來看未來，我們會先將一些不確定因素，先做某種程度的假設(視它為真)，我們才能基於這樣的假設開始作專案計畫，這些assumption要先記錄下來，特別要highlight出來讓大家知道，目的是讓這些假設到時真的成真，否則你的專案計畫就要修改來因應變動，換句話說所有的assumption都是風險，都應該列入風險登記簿(Risk register)裡作風險回應，排除一切會改變的因素。例如我們來讀一下這段情境”某些Critical resources已安排在A專案中支援，A專案執行完成後，剛好可以來支援你的專案”，好各位看出假設是什麼嗎？風險是什麼嗎？假設就是”A專案要on schedule”，風險是萬一A專案如果延誤的話就會影響你的專案進度。所以我們要列入風險登記簿密切注意A專案的進度，有跡象顯示A專案的進度將落後就應該採取行動。
另外一些常見的Assumptions
 Funding schedule
 Activity duration estimation、Activity cost estimation這些estimation都帶有某種程度假設，我們才能預估。
 Critical resources
 產能
 天氣狀況
 市場環境
 各領域有不同的……
一個好的計畫一定要把assumption列入，特別有一個章節來描述，你的計畫相對於他人就更完整，這樣你的behavior改變，PMP這張證照才有價值。
Ocean

 

在Initiation 階段還有許多事情要在這時先收集好或準備好, Identify Stakeholders就是其中一項，找出stakeholder先將他們之間的需求做協調以取得平衡(專案資源有限需作取捨)，並把最後需求列入 Scope statement，用WBS分析成工作，來meet 他們的需求，舉幾個例子來看有那些Stakeholders:
Case 1: 賣場空調裝修工程- 除了大家熟悉的客戶(賣場的廠務或專案經理)，大家常忽略賣場第一線的經理也是Stakeholder，因為你的工程作業會影響他的業績，所以跟他談過以後，他會要你在非假日某時段進場工作、限制施工工作面大小、他會與你談噪音問題、安全問題…，一切會影響他的業務的問題他都會有意見。
Case 2: 大樓建築工程，是否你住家旁曾經有新建工地，曾經有工地派來的工讀生到你家先照相留做憑證，萬一日後工地施工影響到你家才能有一個施工前後的比較，屆時權責釐清才容易，為什麼施工業者要找上你，因為你是該工程專案的Stakeholder，因應風險管理先做回應。
Case 3: 公司內部自動化資訊系統導入- 這個常牽涉跨部門好幾個不同單位的人，它他们會對操作介面、輸入資訊、輸入方式、防呆機制、尋找、例外處理、系統反應速度有很大的concerns對不對，而且大家都不想Key資料，卻都很想要report，每個單位都希望別人多輸入一些，可以分析其他單位的performance來證明自己….，這時就還是回到之前提的，找出stakeholder先將他們之間的需求做平衡(取捨)，然後再放到 Scope statement裡面。
以上這些stakeholders你可以不先將他們 identify出來，你可以在Initiation階段不理他们，可是你現在不先去找他們談，到時候他們就會找上你，到時你的計畫完全無法滿足他們的需求時，你認為專案可以順利進行嗎？聽過”重工”這兩個字吧! 重工代表甚麼？ double time, double cost是不是，有聽說過有那個project plan 它的 contingency reserve, management reserve是兩倍的。If you do not control project, project will control you. 日後會有一堆不在你預期當中的意外出現，你就整天救火吧！誰要你不先Plan好，你的生活就會被你的project主宰。Again, If you do not control project, project will control you。
Anyway, 這些都是知易行難 Ocean

很多人在現實職場中的經驗是老板把我叫去，就assign這個project 給我，要我開始follow up，也沒在開會時當眾宣佈讓大家知道，俗話說: 名不正則言不順，言不順則事不成，所以沒人理我，官小還要到處阿伯阿母(伯父伯母)拜託，這樣專案怎麼能順利，明明是公司的事，確需要用自己的Credit請人幫忙，這樣PM能撐多久。
小project: 至少要老闆發個E-mail通知，藉由這個通知”授權”給這個專案經理去執行專案，就如同欽差大臣需要尚方寶劍一樣，才能整合各部門。沒有必要把Project Charter弄得多正式，重點在於召告天下。
Ex：
專案緣由：理由及預定達成的目的(重要性)
專案經理：Ken Liu, comes from xx department with….
專案目標： 交付物、Completeion date、Budget
專案團隊：須點出要特別support該專案的部門或個人
風險: 特別的品質標準、時程、成本、安全、施工能量(人、機、料)、…老闆總有他(你)的一套，這部分要重點提一下吧！好讓各單位特別注意要多配合。
以上這些都是重點提示，沒有標準答案，不須要去死記，PMP考的是選擇題，沒有填充題，千萬不要去背，考的是觀念。也因為這是管理階層核准的，所以任何的修改調整都要經由核准人同意，這叫做核決權限(level of authority, LOA)，舉例來說，該專案由副總核准，當專案完成時間需延後時，則必須經由該副總核准，否則為何須要他來簽，他簽了其他人可以隨便修改，等於沒簽，這在現實職場環境如此，PMP考試更常考，考得是LOA基本觀念。
中大型project 就照著PMBOK說的做，像是Assumption, Justification…都要列入，因為動支的人力、物力、預算較大，通常都需要做可行性評估(feasibility analysis)，這類評估可以有市場分析、財務分析(NPV, IRR, Cost/Benefit)、技術評估、風險評估…等來佐證，所以上簽呈通常是需要的，我們通常稱 RFA(request for approval)，RFA過了可以等同於Project Charter或經適當轉換成 Project charter。
如果你想要這個專案成功踏出第一步，發出Project Charter(專案核准成立通知書)是必要的，Project Charter本身就是一個很好的溝通工具，不論你是高層還是PM都應該要善用他。
Ocean