Ocean PMP BLOG

原來IE6 無法上來, 所以之前偶有空時想上來看都上不來, 換Google Chrome 終於ok~

剛又完成一輪In-house training, 多少也再得到一些經驗分享感覺不錯~

Ocean

For Example, you're handling a big outdoor activity. Customer only tell you assume how many viewers will come in. this is requirement. But these viewers will generate how much traffic you need to manage, how many parking lot you need to prepare, it depends on many aspects like location, age of viewers.... that is your scope of work. how to turn requirements into scope of work that backend supprt familiar with project needs someone playing this role. Thererfore we need someone to dig out customer requirement, mapping to product and turn into scope of work.

Just like restaurant, service people at the front end msut turn customer needs into product on the menu. Take notes regarding expectations like spicy or not spicy, deliver sooner or normal tempo. and then backend kitchen knows how to delver services.   Project failed often caused by this step at very begining of project. Either needs/wants or expectation, or both are not complete and does not confirm with customer in the course of project.

Ocean

I think the most critical thing to project success is to dig out customer expectation. Customer needs and wants which are often related to product or service is easy to find out.  Customer is hard to tell you clearly what they want. Just like McDonald clerk often double check what you want. 

But how could we know customer really thinking is? I mean expectation. Customer is always looking for better service. In other words they have experienced on previous venders, right?  Therefore “benchmark”  is already resident in customer mind. We often ignore this benchmark and start to deliver on our own way. Apparently, It does not stand on customer position to think what customer expects.

Start to collect historical information customer experienced will be really beneficial to complete your Scope of Work. It means the first activity in your project network diagram is to collect customer historical information rather than start to deliver service you do as usual.

Historical information includes what customer appreciated, compliant. Customer here is at least key stakeholders.

The follow methods help PM keep minimizing gap between project team and customer expect.

http://www.facebook.com/home.php?sk=group_28543375847&ap=1#!/home.php?sk=group_102252159866745&ap=1

價值工程簡單的說就是要找出能用最少的成本創造最高價值的方案

之前參與過道路工程, 有一天大家在想如何保護路肩外橫過高速公路平面道路的橋墩, 在現場工程師討論著如何建防撞護欄及加減壓裝置, 正當此時就看到外勞開著推土機把土堆堆到橋墩週邊, 不花一毛錢把問題解決

再舉一例, 回到公司問題品的處理, 如果能在第一線客服部門先處理掉, 減少後送到二線的量就是價值工程的實例, 這也是客服非常重要的因素之一, 當然一線有一線依據客戶的狀況有不同的解決方案, 二線亦是

Ocean

Games people play,

Never meaning what they say, yeah
Never saying what they mean

http://www.youtube.com/watch?v=KmM0BZMJJSE

http://www.youtube.com/watch?v=5znh58WITU8

成本與品質與時間與範疇總是在不斷的拉扯到底那個重要，一般來說Matrix組織垂直式分工，各部門各司其職，規劃部門與產品部門當然以成本為第一考量，他們的KPI往往是 cost down多少， profit 增加多少，品質時間是其他部門的事，製造維修單位總是高舉品質大旗，quality is plan in要求規劃部門優質設計，多編列預算買好的設備，最好是全自動零故障，若日後運作有問題那是規劃部門問題，業務部門不管你用甚麼設備多少錢品質如何只要時間與範疇能做到可以驗收請款就好，那個部門可以全面的來看那就是PM, PM通常比較客觀站在比較接近公司整體利益來看(當然要看那一層的PM)

Ocean

What is next step when finishing hearing(requirement collection), most of you will say no doubt staring WBS.

Do not forget project we have triple constraints(scope, budget, time, quality, customer satisfaction). Project always couldn’t fulfill every stakeholders’ wishes.

All project have is limited budget, nailed down time line to deliver service/product to customers. Inviting big-stakeholders gathering to sync with each other. you can take advantage of PMO meeting or other high level meeting to do this. Do not try to satisfy every thing these big-stakeholder required. To balance their needs is essential, it’s trade off, sometimes it’s dilemma but PM must have this sense to make it happen in the very beginning of project.

Ocean

Project Management Office(PMO)

目前市場的競爭瞬息萬變, 年初的計畫說不一定Q1還沒結束就需要調整, 尤其在產品推陳出新高度競爭的環境中, 每年的計畫一定與市場上其他競爭者的策略相關, 這些競爭者怎麼出招當然無法一時之間全盤瞭解, 所以企業就必須作出許多未來市場上變化的假設(想), 然後根據這些假設來做計畫, 好! 之前提過只要是假設通通都是風險, 而且這種未來市場性的假設都是很大的風險(fundamental risk), 剛簽完的合約產品要交付的時間或型號或數量可能隨著市場變化馬上就要變更, 因為Time to market, 所以為了因應需求改變所導致的變更要求, 這樣的變更要求當然不是PM及其承包商PM這兩個人就可決定, 尤其是大規模的合約這種大部隊作戰, 包括陸海空(各種相關project)聯合作戰是需要有一個類似戰情室的組織, 來權衡接下來的作戰方式, Change control board的層級(通常由經理組成)無法作出與企業層級策略上(corporate strategy)的相關的改變, 這時就必須要成立Project Management Office這個組織, 這個組織不只包括公司高層還要包括相關承包商/供應商/連鎖業者…的高層, 因為這是一個聯合作戰需要各團隊有決策能力的人來組成, 隨時調整腳步這樣的調整要跨部門, 跨合約, 跨流程, 方向要改變要每個管理階層都買單否則又會是溝通不良產生不必要內耗的開始,要怎樣才能讓這樣的組織運作起來會有效率, 如何運作待續~

PMBOK上PMO的定義如下

• PMO is a department that centralize the management of projects

PMO plays one of three roles:

用風險分數來做決策(Decision Making)

在一般日常的營運我們還是不斷地會做一些改變或改善，當然這些改變或改善背後的目的無非是想要提高營運的效能，好比說新設備引進改變工廠的內部空間配置(Layout)，相關設備需要搬移，動線需重新規劃，好比設備汰舊換新，軟體昇版…..，當然這些是為了提昇營業效能必要的變更要求，問題是在什麼時後來做，用什麼方法來評估時機是否成熟，意即當我們作好一切準備，該變更預期的風險會降到我們可接受的程度，這個時間點就是執行變更的時候。

適當的運用風險管理(Risk Management)中風險分數來做決定，這樣來看-因此變更所產生的各種大小風險(可用反魚骨圖來找出各種風險)是否都得到適當的回應(Response)，再來是這些回應執行後各項風險其風險分數是否有持續降低，當整體風險由大風險->中風險->小風險就是執行的時機，否則沒有一套機制來評估，只是憑經驗常陷入兩難(dilemma)是動還是不動這把尺真的很難拿捏。

公司可以發展一套風險管理機制對營運上的變更會有所幫助，如何落實要先了解PMBOK 風險管理機制稍做修改即可運作。

Note: 如合定義可能性(Possibility)及發生後的影響(Impact)，回應的策略，風險門檻….應要有一致的標準

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

我們設計或說合約在規定付款，除了預付款(Down Payment)外，多少會結合收料或初驗(商業運轉前)這些時間點，那也就意味再商業運轉前或驗收前，該系統或設備屬於承包商的，相關的維運也會是承包商，但過了商業運轉或驗收後，則財產及維運權責就會自然轉移到甲方，想當然甲方對系統或設備沒有乙方來的熟，所以才會設計要這麼多的文件，來確認是否承包商把該交付的是否都執行了，或者是甲方是否都完成維運的準備了(Operation Readiness)，這些文件譬如說教育訓練簽到簿、備品清單、設備維修更換流程(Repair and Return process)….

Ocean

剛過完中秋辦公室桌上多少擺著一兩顆還不知道什麼時候才要吃的柚子, 隨著日子一天一天過, 柚子漸漸的由綠變黃再變成紅, 就像專案風險管控一般, 如果不做 專案風險燈號就一樣會由綠燈變黃燈再變成紅燈

專案風險管控執行時最常遇到的障礙就是聽到team member 說: 怕什麼船到橋頭自然直..不要杞人憂天..找麻煩 .之類的話,  或是 他自己會是Risk owner 多一事不如少一事, 如果你是PM要如何回應, 總要先準備一下吧!

Ocean