Ocean PMP BLOG

I just want to remind you when company provide staffer award that a special gift other than money is required.
Because special gift is kind of limited power like a 獎牌、座. Only you and minority in company could own it and show off.

 
這句話大家都熟，考試也考，問題在怎麼做，品質標準對生產單位來說是相對明確的，但對於非產品的服務一樣要訂定品質標準，這個品質標準對於產品來說就是合格或不合格判定，對於非產品諸如系統昇級、改善就是成功不成功的判定(Factors of Success)。一般的習慣是把專案做完就好而不去考量專案進行過程中所造成的影響，在live的系統中做改善或昇級，應該要有那些判定成功與否的因素，其中包括專案進行中的品質標準及專案完成後預期達到的品質標準

同樣地賣方寫的建議書買方不見得完全瞭解，單憑書面資料也未必能證明賣方的能力，所以買方在收到建議書後就會請各賣方前來說明(Presentation)。召開說明會後，買方即可運用先前制定的評選標準評定賣方建議書，最後選擇一個或多個合格的賣方(Short list)開始進行磋商(Negotiation)，磋商的範圍包括建議書中技術(Specification)、商業(Price)、合約條件(Contract Term&Condition) 及專案管理部分。最後專案團隊及採購部門會將磋商的結論呈報管理階層召開經營會議(Executive Committee)做最後決定，將該合約給那一家賣方(Contract Award)，最後完成簽約。

當買方寄出RFP給賣方後接下來該做什麼，等賣方的建議書(Proposal)嗎？這樣來看你(買方)認為你寫的採購文件(RFP)裡面的需求、專案範疇、合約條款、特訂條款、投標需知、答標方式、及各種附件，這些收到RFP的潛在賣方都充分瞭解嗎？如果答案是否定的，就會影響賣方的投標意願、解決方案及價格，為了要縮小買賣雙方對於專案範疇內容的認知差距，所以買方都會發起一個會議邀請賣方到場針對RFP不清楚部分發問，這個會議叫做投標商會議(Bidder conference)，即是讓潛在賣方準備建議書前的會議，會議進行時買方應公平的讓賣方逐一提問及回覆(不一定當場回覆)，最後回覆澄清的內容需作為採購文件(RFP)的修改文件
(Amendments)，效力超越採購文件(RFP)。當賣方充分瞭解RFP的內容後即可開始撰寫建議書(Proposal)。
Ocean

在完成了外購的範疇(Statement of work), 我們也選擇了最適合的合約類型後, 接下來就是準備要讓潛在的供應商(系統整合商)提出解決方案(Proposal)來滿足你專案外購的需求, 因為我們要Proposal所以我們要提出一個RFP(Request For Proposal)告訴潛在的供應商(系統整合商)提出解決方案(Proposal), 所以在RFP裡除了外購的範疇(Statement of work)外我們還要加上各種合約條文來限制甲乙雙方的權力及義務, 例如交期, 付款條件, 罰則, 合約爭議處理, 合約中止, 違約, 不可抗力...這些合約條文一般在大公司的法律部門都有標準版本的中英文合約(Standard provisions), 我們稱這些合約條文為 clause, 總稱為 Term&Condition, 除了這標準版本的條文外每個專案都有其差異性, 這些差異需要供應商(系統整合商)或甲方(buyer)特別遵守的稱為特訂條款(Special provisions), 例如系統或產品規格, 專案特別需求(標準條款沒有), 這些條文會影響供應商的投標意願及報價, 專案經理也要確認透過合約條文將風險轉移給供應商, 所以專案經理要參考自己的主約條文然後back to back 將風險(例如交期,罰則,品質...)透過合約條文轉移出去, 所以專案經理必須要參與採購流程

接下來再將評選標準, NDA(Non-disclosure Agreement), 投標/答標說明及邀請函附上我們就完成RFP, ex:如下:
 
Procurement Doc.RFQ? RFP?IFB?

採購流程大部人都是部分參與難得窺得全貌，一來說需求人員通常會先準備三家報價，然後上個採購單(Purchase Order), 複雜的系統就加些系統規格要求，然後就看採購了，有進一步消息或活動採購會通知，大概時間快來不及時才會摧一下進度，事實上PMBOK講得採購與一般實際運作基本上幾乎一致，下面就讓我們來順一便，採購是流程導向的(process driven)，每個流程間是有清楚邏輯關係，少了一步驟就不完整。
1. Make or Buy analysis: 根據成本效益(cost benefit analysis) 來做分析、再加上考慮是否有特殊技術、配方需自行生產
2. Statement of work: 寫下決定外包的工作內容
3. Contract Type selection: 依據買方對合約工作內容(Scope of work)的掌握度，來決定選擇那一種合約型態發包(outsourcing) 

許多老闆都知道風險管理很重要, 可是說到要如何做, 大家確都是嘴巴說說沒人知道該怎麼做, 另外一種就是把問題point out出來然後沒有任何solution, 問題我點出來了發生不要說我沒提醒, 其實我們要的不祇是發現潛在問題, 怎麼解決及是否有效才更重要, 下面列出方法步驟照著做即可
1. 找出風險(risk identification): 將專案管理計畫(requirement, Scope of work, WBS, schedule, Qualty plan, ..),合約(term&condition, technical specification)拿出來分析是否有不確定因素存在, 再訪談利害關係人將這些可能的問題找出來列表
2. 定性分析(Qualitative analysis):將這些風險依影響專案目標達成的嚴重性分成大,中,小三類風險, 可評經驗綜合判斷風險大小, PMI的方法是用風險分數來決定, Risk scoring=P*I, Probability: 該風險發生的機率, Impact: 如果該風險發生後對專案目標(Time, cost, scope, quality)的影響大小. P與I都用小數來表示, ex: 0.7*0.4=0.28
3. 定量分析(Quatitative analysis): 針對大,中風險因為對專案目標影響大, 所以須進一步做量化分析, 這一類分析可用機率分析(Monde Carol)或What if(試算)來模擬該風險如果發生對專案目標的影響有多大, 機率分析可以跑出專案完成時程或成本的各種機率(ex: 3/12完成的機率是多少, 那3/20完成的機率是多少, 專案完成時成本是100萬的機率是多少, 105萬的機率是多少)真正大型專案才建議用Monde Carol因為你要得到如此精確的分析, 必須要將每個活動的連續機率估計都輸入才可能達成, 一般專案我們用Microsoft Project 來試算(waht if)即可

PM的好朋友"要徑" Helps the PM:
要徑就是網路圖(Network diagram)上時間最長的那條路徑, 如果兩條路徑時間一樣長那就有兩條要徑, 要徑在專案計劃確定時會有計畫的要徑, 可是專案一旦開始執行要徑會隨時變動, 當然如果當初計劃準確控管也良好, 要徑應該要如計畫時預期的, 要徑一旦確定後(至少要meet project charter 上的專案完成日), 可以幫助專案經理做下列事項.


1. 決定專案需要花費多久的時間

•

6.   非要徑活動資源視需要應調往要徑活動上

7.   計算浮時(Float/Slack)

8.   做為重新估算及風險評估的主要對象

9.   資源撫平時作為調整判斷

 

Ocean

Scope verification 會發生在專案每個 Phase 結束時, 要將 deliverable 交到客戶手上, 並得到客戶的簽收(acceptance, sign-off)所以是與客戶相關, 當然交給客戶時也會確認交付的數量及品質是否經過QC(Quality Control) 檢驗完成可出廠.
Quality control 就是內部針對產品或服務所做的量測(measurement), 看是否符合Quality Planning時訂出的Quality Standard 與客戶簽收無關
所以QC與Scope Verification可以同時發生, 兩者都會驗證產品或服務的正確性(Correctness)
Ocean