Ocean PMP BLOG

PMP Exam Formulas:

1)       Financial method of project selection:

學員常弄不清楚這兩個 term 的意義，及如何運用
Know unknown: 已經被 identified 的風險，發生的機率未知，列入風險登記簿作風險回應(risk respond planning)，將其發生機率降低。

這次行程我最擔心的是天氣，說實在我還沒在低於5oc的環境待過，最接近的那次是在合歡山，記得真的是寒風刺骨，雙手刺痛。出發前特別請教過幾位曾待在美國的朋友關於Minneapolis的天氣，每個人都說要帶大衣並把體溫容易流失的部位保護好，像是帽子、圍巾、手套、高領毛線之類衣物，所以我一半的行李箱都裝這些厚重的衣物，誰知真是計劃趕不上變化，來接待我們的人說: you’re lucky the weather is so good, it’s exceptional, I’ve never seen this before，連續幾天好天氣非常舒適，唉！沒想到想摸個雪都這麼難，直到要離開那天天氣才轉涼開始下雨，看了氣象報告隔天會下雪，雪特! 真是造化弄人，沒雪只有雪特，大概我们前腳上飛機離開，雪隔天就給它下下來，話雖說如此，其實真的是感謝老天幫忙給我們舒市適天氣。
星期日當晚到達機場，輪班的計程車司機老大說他排了3個小時才輪到班，上星期六還排了6個鐘頭，可想而知景氣有多差，隔一天就要選舉，沒看到隨風飄揚的旗幟，沒有T-bar廣告，沒有宣傳單，也沒有宣傳車大街小巷的廣播，安靜的很，如果不看新聞還真的很難查覺他們在總統大選。稍做休息了一晚，其實我帶了安眠藥，但最後還是沒吃，所以晚覺都當午覺睡，最後一天下午的課我和David注意力已經很難集中， 我看David 幾乎沒甚麼睡，晚上還在處理台北這邊的事情，大概都在下課後睡，所以那個法國餐廳的領班大概覺得很困擾，為什麼我們總在他快要下班時才去吃晚餐，其實我們也是千百個不願意~
原本這次行程在9月就要成行，後來因為颱風當天班機取消，飛到L.A.時下機後開了手機沒訊號，索性也就關機，直到星期一早上才開機，一開機就收到簡訊，簡訊內容是”你叔叔生病住進台大請快過去看他…”，不會吧! 這個距離有點遠吧，這裡沒有捷運可到台大下車，趕快連繫了老婆其實她已經在照顧沒大礙，也感謝同仁幫忙. Ocean

花了半個月把 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
 
 
 

一早媽媽就催促著哥哥要起床上學、吃早點否則就搭不上6:50那班客運，然後叫弟弟、妹妹起床，一起床兩個在飯桌前坐下，又為了誰該吃那一份開始要衝突起來，媽媽馬上要過來排解，好讓早餐準時結束以免遲到，在出門前還要再提醒該帶的書、便當、美術課的水彩帶了沒，下課後要聽小孩在學校的發生的事，遇到挫折要安慰他，做對給獎勵，做錯要罰，要幫小孩複習功課，要簽聯絡簿來瞭解今天有什麼作業，小孩在學校表現如何？明天該準備什麼，當小孩數學、英文較弱時，要找好的補習班補習而且還要考慮預算。
各位有沒有發現媽媽做的事，就跟專案經理做的事一模一樣，家裡的事該做一樣不能少(scope)，每天家裡成員的活動都在媽媽掌握之中，媽媽會不斷提醒時間到了，什麼該開始，什麼該完成(time)，據統計80%家中的預算由媽媽掌管(cost)，家裡成員的需求，舉例來說爸爸要刮鬍刀、兒子要買球鞋、女兒要買洗髮精，最後要採購的決定權及要採購的對象，通常由媽媽決定(procurement)，因為媽媽瞭解是否家裡還有沒有庫存未使用的，要到那間賣場買較便宜(select sellers)，如何討價還價(price negotiation)，買多少可以換到折價卷，那間可以換到家裡需要的贈品，媽媽是個需求整合者(integrator)、採購經理(procurement Mgr.)、訓練經理(HR training Mgr.)。舉凡大大小小的事都要她。爸爸大概可以算是個 team member聊備一格，有時還不夠資格，有時還自認為是sponsor(發起人、贊助人) or 管理階層(management)。
我每次上課第一件事就是注意參加學員男女的比例，目前大概是男七女三，我覺得這個比例該大幅調整，起碼5:5，反過來才正常，因為女孩子天生就是做 PM 的料。
Ocean
 
 
 

這是大多數學員常感困惑的兩個名詞，尤其是缺乏實務經驗的人
。在大公司待過一年以上的人，大概都知道Quality Audit 這件事，大公司常設有QA這個部門，因為公司的ISO程序非常多，管理階層無法確知各個部門是否都照著程序做事，所以老闆”不放心”，此時QA就發揮功能，QA會在各單位培訓了許多Auditor，這些Auditor會定期跨部門去查核各單位(包括Project)是否照程序執行並給建議，所以Auditor來時我們要把程序書、表單、記錄、缺失矯正單(Corrective Action Record)排列出來，如果你有照著程序書做，那就一定會有記錄，一定會有自我檢查發現不合格問題的缺失矯正單，這叫做structure review，所以QA一定是”事後”去查， QC則是配合製造、coding….完成時執行。
答題判斷關鍵在是否是”事後”去查。另一個是當管理階層” 不放心 no confidence””擔憂 worry about”考題有這種字眼出現時就選 QA。
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)
 所以初步專案範疇說明的主要目的是要讓專案經理與專案發起人之間對於專案範疇有共同的理解或交集

大部分小的專案通常由老闆指派，目的不外乎商業需求、問題解決、提昇良率、流程改善…但公司(你)的資源是有限的，當有多個中、大型且長期提案要面臨選擇時，該如何抉擇呢?用甚麼方法，其實這也就是 Decision Making，今天來介紹以財務角度來選擇看那一個專案有最大的潛在利益。
例如目前有兩個專案，專案A在一開始需要100,000一次性建設費用，專案B在一開始需要300,000一次性建設費用然後在各年的成本及收入分別如下:B略
Project A
______Cost/ Rev./ Balance/ PV
0 year 100,000/ 0/ -100,000/ 100,000
1st year 20,000/ 10,000/ -10,000/?
2nd year 20,000/ 20,000/ 0/?
3rd year 20,000/ 30,000/ 10,000/?
4th year 20,000/ 40,000/ 20,000/?
5th year 20,000/ 50,000/ 30,000/?
現在問題來了，第0年、第1年的、第2、3、4、5年的 balance(收支相抵)可不可以直接相加? 再問一個問題，你的朋友跟你借100萬，三年後應該還你的錢，與四年後該還你的錢是否一樣，不會是一樣吧！問題出在利率(更正確應是discount rate 貼現率或折現率 ，折算成現值的比率)這個因素，那要怎樣才能讓這些不同年份的值相加，很簡單就是先通分，把第1年的第2、3、4、5年的 balance，都換成第0年的值，就是PV(現值 Present Value)，把這些現值加起來就是淨現值(Net PV)，所以NPV愈大愈好，代表該專案愈有利可圖，考試就考這個，現值如何轉換就無需在此多著墨。這些都是Hard skill容易理解，難是難在如何控制你的cost，如何帶進預期的Revenue，去meet如上面表格計劃的數字，好讓你的NPV值儘早由負變正，這才是學問。你的Behavior改變，對公司有貢獻，PMP這張證照才有價值，再來談加薪…
PV=FV / (1+r)n ，FV=future value ，r: 貼現率或折現率 折算成現值的比率，n = number of time periods
NPV= Co + C1/(1+r)0 + C2/(1+r)2 + C3/(1+r)3 + …. ，Co : 第0年一次性建設成本(現值)， C1 :第一年收支相減，C2 :第二年收支相減，r: 貼現率或折現率 折算成現值的比率。
Ocean

這三個名詞常容易搞混，考試就在考這基本觀念
Program vs Project : 9年前進公司是待在 Network Division Program Management Team(網路處專案管理部)，那時亦有點弄不清處 Program和 Project有何不同，我們有好幾個PM負責好幾個Project，固網在開台初期建設量是非常大的，參與的vender也都是國際大廠，Contract value當然是億來億去，後來弄懂了，我們提供電信服務給客戶，幫客戶傳遞的訊息是需經過不同的設備轉換的才能到達目的，因為整體的建設量及複雜度很高，控管不易，也因為沒有一個 vender可以在每種設備都勝出，所以對我們業主來說，將一個大的建設案(Program)，分成多個專案(Project)分開招標執行，做好介面管控，對業主來說是風險最小的。
Project vs Phase:
CaseI: 有階段性建設需求，將專案範疇適當切割成好幾個階段來執行(By phase)，好處是不需要一下子投入大量的人力、物力，一般公司組織都是以routine事務來規劃人力配置，所以最怕的就是工作突然爆大量，by phase就如同 resource leveling一般可以達到一定壓低資源需求的功效。
Case II: 還有一種要注意的就是客戶也不確定他的需求是多少，因為市場變化很大，連他亦無法預估，這時有經驗的專案經理一定要 by phase來做，不然你會因為客戶業務量不夠，讓你無法將合約所定足夠量的產品或服務交給客戶，就這樣專案一直拖著無法驗收，無法驗收就無法請款，無法請款就無法進入保固，損失會很大，對公司也無法交代。
CaseIII: 再一種對於不熟悉的範疇(Scope of Work)，最好by Phase來執行，透過與客戶誠懇的溝通與分析，這樣到頭來看時程反而會縮短，成本及風險都可大幅降低。重點在Phase I
Phase I: Prototype(軟體或硬體設備原型機), Trial run(試做試運轉), Demo Site(作示範)
Phase II: Typical 點
Phase III: …
Ocean