Ocean PMP BLOG

 
如果是甲方，我們在執行專案付款時總是會要求承包商要附上一堆文件(Supporting Document)，等都備齊了才會再證明書(Certificate)上簽字，承包商才會根據此證明書作請款，時間一久執行的人換了好幾手，大家也忘了為什麼要承包商附上這一堆文件，只知道用這個好像可以卡卡包商，但對自己公司有什麼用，大部負責請款的可能沒想那麼多。

剛過完中秋辦公室桌上多少擺著一兩顆還不知道什麼時候才要吃的柚子, 隨著日子一天一天過, 柚子漸漸的由綠變黃再變成紅, 就像專案風險管控一般, 如果不做 專案風險燈號就一樣會由綠燈變黃燈再變成紅燈
專案風險管控執行時最常遇到的障礙就是聽到team member 說: 怕什麼船到橋頭自然直..不要杞人憂天..找麻煩 .之類的話,  或是 他自己會是Risk owner 多一事不如少一事, 如果你是PM要如何回應, 總要先準備一下吧!
Ocean

嘿！想想我們上班走的路徑已經多久沒有變動了，那天順道載了同事下班談起來才驚覺我花了許多冤枉時間，原來還有其他的捷徑或是可走新的快速道路，想想我們上班的工作流程已經多久沒調整了，習慣成自然有時就是需要一個外面的人來提醒我們，流程改善指的是一點一滴的調整，是不要花費大量資本支出(CAPEX)的才對，有人說花一筆錢買新設備品質不就可以馬上改善，我說那叫投資不是流程改善，大量資本支出會造成成本上昇，這與我們做流程改善來降低成本的目的剛好背道而馳。
什麼叫做一點一滴，舉個例子在”我在漢堡店臥底的日子(My secret life on the McJob)”書中及”便宜是好事(Treasure Hunt-Inside the Mind of customer)”兩本書中都提到之前麥當勞改善”得來速”服務的例子，根據一項調查顧客在”得來速”點餐等候的時間比溫蒂漢堡或奇克炸雞連鎖店的汽車點餐服務多出6秒(有時甚至好幾分鐘)，乍看之下這個數字或許無關緊要(說實在6秒鐘對一個員工(更不要說工讀生)來說實在沒有什麼感覺，有什麼好計較對吧?)，但是對一個店的營運(假設每天有100車次在用餐時段來得來速)來說就顯現出效果，很明顯在用餐時間就可多銷售兩、三個客戶，這樣的改善對於區的營運會是怎樣的，對於全美1200個以上提供得來速服務的分店會是怎樣，對於在全世界擁有31,000個分店的麥當勞你想會產生多大的影響，每位顧客幾秒鐘的差距背後代表的就是幾十億美元的商機。麥當勞針對每部車進入得來速車道排隊到點餐再到外帶離開這段”開車時間”的每個環節加以改善，希望每次汽車外帶餐點時間能再降低。 ”便宜是好事”書中提到影響汽車點餐速度的原因很多，從水準不一的員工服務到不當的包裝都有可能，所謂不當包裝包括包裝過大，很難從窗口遞出；飲料杯太大放不進一般汽車杯架；調味包設計不良，不容易打開等。有趣的事是關於水準不一的員工服務可以從”我在漢堡店臥底的日子”書中窺知一二。
宣明智有個有關流程改善降低成本的小故事，有一次他在與員工溝通降低成本時，員工問他現在售價是10元我們成本是5元為什麼我們還要一直降低成本到3元，宣明智說如果有一天當市場價格開始下滑，下滑到5元時如果沒有做流程改善降低成本，我們成本還是5元就沒有賺錢了，但是如果我們現在做到時別家已經沒有利潤了，我們還賺2元。
 Note: 當你讀完”便宜是好事”後再看看”東西的故事(the story of stuff)”這本書時真會讓你百味雜陳，在我們享受資本主義帶來的科技進步的同時，我们的環境及個人的健康(由其是環保法令較寬鬆國家的民眾)也被糟蹋的可以，其實東西真的沒那麼便宜，當你看完”東西的故事”就知了。

今天同事談到他小孩參加夏令營回來，說活動的名稱是”互助合作”，不是”分工合作”，我們來比較一下這兩者間有何不同，談互助合作我們想到比較接近的是”團隊合作”，看看棒球比賽一壘有跑者，打擊者擊出滾地球，二壘手出來接，游擊手會過來二壘補位好封殺跑向二壘的跑者，這個大家都同意也認為是理所當然，可是把場景拉回我們目前的工作環境，如果你是那個二壘手你認為游擊手會過來補位嗎? 游擊手會告訴你我的JD(job description)裡面沒有我當二壘手的要求，最後還是要你自己跑回二壘不是嗎?

上星期日David打來說Rita過逝, 我想對於絕大部份的 PMP在考試前一定都看過她這本參考書, 前年見她時其實本人已經比書本上照片清瘦許多, 如果沒特別介紹是認不出來的, 不過接待我們那晚她精神是非常好, 思緒非常清楚也很健談, 她說她每天在湖邊打太極養身(住家在明尼蘇打拿玻里市一處湖邊), 想說應該是在康復中沒再問病情, David說在過逝前幾天她還在錄製課程, 可見她對於project management 非常有熱情, 昨晚把她送的Risk Management這本書拿出看, 第一頁還有她的簽名, 睹物思人, 在我研習專案管理這門課題時, 在我讀這本書不禁贊歎作者清楚邏輯時, 也同時知道作者的部份故事會更有感觸~
Ocean

我們在做大量建制(roll out)時，如同部隊作戰打的是補給(logistics)，即是預算是否編列，物料合約是否簽定，採購單(PR/PO)是否已發出，然後是物料是否到位，有了穩定的補給線，大軍才能無後顧之憂的照計畫攻城掠地。
PMBOK中並未特別強調物料控管重要性(procurement 中提到的是採購的策略及流程)，但在一般實務上確是常發生的問題，專案經理除了把 scope, time, cost, quality, HR, communication, risk, procurement, integration 管理好外，物料是否能持續穩定的供應，時常是roll out專案執行成功的關鍵，這就是所謂的[大軍未發，糧草先行]。
Ocean

 Ask yourself can you figure out what's differences between these 3 terms.
Most of cases we can not exactally tell what distinctions they are, can we?
Generally speaking, we address these 3 as following.
Scope: to deliver 300 sets xx equipment to Tokyo Japan, by Y10.

絕大多數上課學員都沒想過管理者把公司組織架構設定成何種模式會深深影響專案經理的表現或者說專案的成功與否:
 
1. 功能性組織(Functional Organization):

 When we run project, especially in execution stage there is always Eng raises their hand saying oh, I can not accept this feature due to …what if …….
You know they do not know what contract scope defined. They sometimes try to protect themselves and ignore contract SOW.
PM should be aware of following contract is the first priority otherwise scope is going to be divergence. SOW can be revised but should follow Change Request process. We have change control board to determine Go or No Go.

專案開始之初在Planning 階段之前我們先要做Stakeholder analysis，目的是要瞭解會影響專案成敗的有那些人，這些人當中除了負責專案實際執行的專案人員外，主要的Sponsor(ex: 各部門主管)針對這個專案它們的看法是甚麼，講白一點他們的需求是甚麼，如果沒有先談好加以收斂，注意這些需求是會不斷的出現變成Activity加入Scope裡，憑專案有限的時間、資源是沒有辦法滿足這些重量級Sponsor的需求，缺了先做 balance stakeholder needs 就進入planning階段就會漏掉這些non-business needs，日後就會有人不斷舉手告訴專案經理，他們老闆要求還要加入一些activity，專案是要拒絕還是接受(專案有專案的kpi 時間成本…,各部門有各部門的kpi),  balance stakeholder needs講白一點就是在滿足專案這個goal的前提之下，大家共體時艱來完成專案，balance stakeholder needs就是要大家先各退一步，以此為基準線來作為專案的Scope，不然Scope creeping或 change request 會不斷的出現。